Attiny2313 niet goed na erase

Er zit toch geen bootloader in? (want die is na erase natuurlijk ook verdwenen dan...)

Programmeer je in-circuit?
Zou het kunnen dat er ergens een peripheral over z'n nek gaat van die sequence?

Normaal is een 'chip erase' precies dat. Soms kun je flags setten dat-ie van EEPROM af blijft bij erase bijvoorbeeld. Dat noemt fuses. Die dus eens uitlezen en kijken of daar wat dwars zit.

Heb je je Fuses wel goed staan ?

Volgens mij staat alles goed en staan de fusies ook goed.
Een nieuwe waarbij ik geen erase doe werkt perfect.
Ik programmeer niet in het circuit. Programmeer met een galep rechtstreeks de chip.
Dus enkel een geprogrammeerde chip die ik erase, of (zoals ik eigenlijk automatisch doe, een nieuwe ongebruikte chip die ik erase) werken niet.
Eentje die ik niet erase en waar uiteraard nog niets ingeprogrammeerd staat werkt perfect.
Met de erase wordt er dus iets uitgeschakeld wat niet de bedoeling is.
Maar de vraag is dan eigenlijk, hoe zet ik dat terug (indien mogelijk)

Ik vind het maar vreemd.
Een chip die nog niet geprogrammeerd is en toch goed werkt?

Maar bij een erase gaat zowel het flash geheugen als het Eeprom geheugen leeg. Maar die zijn allebei Ok, want bij een korte spannings-dip werkt het wel weer.

Waarschijnlijk toch iets mis met de fuses. Als de chip met de nieuwe fuses sneller werkt dan kan het wel eens te snel worden. De meeste displays hebben na het opstarten een vertraging nodig voordat je ze kunt gebruiken. Dus ik zou eens proberen om de fuses van een nieuwe te vergelijken met de fuses van eentje die niet meer werkt. Zou goed kunnen dat die galep bij het wissen ook de fuses omzet..

Zitten er fuses in de hexfile?
(De Galep inetersseert het niet, die programmeert erin wat je 'm geeft, met of zonder fuses)

Op 19 januari 2019 19:18:07 schreef deKees:
Ik vind het maar vreemd.
Een chip die nog niet geprogrammeerd is en toch goed werkt?
..

Haha jaja, nee zo bedoel ik het uiteraard niet.
Ik programmeer wel mijn hexfile erin.
Maar doe ik dit na een erase (of die chip nu nieuw is of geprogrammeerd is geweest met een andere file) dan werkt ie niet goed.
Programmeer ik de hexfile in een nieuwe chip zonder erase dan werkt ie 100%.
Na een erase wordt er dus iets weggehaald wat niet moet. Tot nu toe niet erg, maar hoe krijg ik dat weer ongedaan/terug

Lees eens de fuses uit? Na een erase, en nadat je de software erin gezet hebt?

(Wat ze in een hagelnieuwe horen te zijn staat in de datasheet. Wat ze zijn nadat je de software erin gezet hebt kan anders zijn als daar fuse-informatie in zit, maar anders blijven ze hetzelfde. Bij een erase zouden ze ook hetzelfde moeten blijven... ténzij! je programmeersoftwaretooltje ze dus aanpast.)

In het slechtste geval kan je een fuse repair bordje gebruiken.

Nee hoor, in het slechtste geval gebruik je zo'n bordje, en werkt het niet, omdat je niet de default fuses nodig hebt.

(Trouwens, hij praat nog met je programmer, dus je hoeft geen hvsp te gebruiken.)

_{Oh, ik weet een nog slechter geval. Ik heb een attiny45 gebricked door dwen en ckdiv8 aan te zetten bij 128 kHz interne clock. De attiny45 doet geen HVSP, en via ISP kun je er niet meer bij (want dwen aan), en via debugwire werkt ook niet (Want klok is te traag).}

_{Het kan nóg slechter trouwens, als je vrouw ervandoor gaat met een toreador, je goudvis van doublé blijkt te zijn, en je vouwfiets bij het vouwen helemaal geen vouwfiets blijkt te zijn. En bovendien de wereld vergaat.}

Oh, ik weet een nog slechter geval. Ik heb een attiny45 gebricked door dwen en ckdiv8 aan te zetten bij 128 kHz interne clock. De attiny45 doet geen HVSP, en via ISP kun je er niet meer bij (want dwen aan), en via debugwire werkt ook niet (Want klok is te traag).

Dat zou nog op te lossen zijn met een externe clock

Het kan nóg slechter trouwens, als je vrouw ervandoor gaat met een toreador, je goudvis van doublé blijkt te zijn, en je vouwfiets bij het vouwen helemaal geen vouwfiets blijkt te zijn. En bovendien de wereld vergaat.

Ben je de Dalton's niet ergens vergeten?

Op 20 januari 2019 11:41:06 schreef Lucky Luke:
Nee hoor, in het slechtste geval gebruik je zo'n bordje, en werkt het niet, omdat je niet de default fuses nodig hebt.

(Trouwens, hij praat nog met je programmer, dus je hoeft geen hvsp te gebruiken.)

_{Oh, ik weet een nog slechter geval. Ik heb een attiny45 gebricked door dwen en ckdiv8 aan te zetten bij 128 kHz interne clock. De attiny45 doet geen HVSP, en via ISP kun je er niet meer bij (want dwen aan), en via debugwire werkt ook niet (Want klok is te traag).}

_{Het kan nóg slechter trouwens, als je vrouw ervandoor gaat met een toreador, je goudvis van doublé blijkt te zijn, en je vouwfiets bij het vouwen helemaal geen vouwfiets blijkt te zijn. En bovendien de wereld vergaat.}

TS geeft aan dat het bij een 'frisse' ATtiny2313 net wel werkt. Terug zetten naar de start instellingen, ook al is het via een hvsp, brengt je terug naar start. TS heeft het ook niet over een ATtiny45 maar een ATtiny2313. Die is wel terug te zetten naar standaard met een hvsp.

CKDIV8 is een fuse die standaard aan staat. Je moet ze deze dus niet meer aan te zetten.

De TS geeft ook aan dat hij de "foute" 2313 weer kan starten met een dip in de voedingspanning. Volgens mij vraagt dat om een trage start met de fuse voor de 65ms opstarttijd. zo uit mijn geheugen is dat een optie bij de interne 8MHz fuse.

Misschien is het wel handig als de TS even alle gebruikte fuses hier vermeldt.

Als je de programmer vraagt om een erase, lijkt het me logisch dat alles gewist wordt, ook config fuses e.d.
Die moet je gewoon opnieuw meeprogrammeren...

Nee, fuses worden normaal niet veranderd bij een chip erase. Maar het zou wel kunnen dat die Galep daar anders over denkt.

Fuse data staat ook meestal niet in de hex file, dus de programmer weet niet hoe ze moeten staan, tenzij je daar speciale instrukties voor geeft.

Ik vond het niet logisch, maar roep niet graag iets voordat ik het heb getest.
Net even een chip erase gedaan en de SUT_CKSEL fuse waarmee de clock en opstartvertraging wordt gezet blijft intact bij een erase.
Maar, ik heb geen galep... dus het bewijst nog niets.

De Galep is een universele programmer, die bij een erase gewoon zorgt dat alles in een chip gewist wordt (of dat nu een MCU, (e)eprom, PLD, of wat anders is)
Waarom zouden fuses niet gewist moeten worden? Je weet toch niet of ze bij de volgende programmering hetzelfde moeten blijven staan?

De EESAVE fuse bepaalt of de eeprom inhoud wordt gewist bij het programmeren.
Als de ALLE fuses worden gewist bij programmeren dan ook de EESAVE en daarmee ook de eeprom inhoud. Een zeer ongewenste situatie!
Wat je schrijft is dus niet logisch.

Ik heb al heeeel veel MCU's geprogrammeerd, maar bijna nooit de eeprom inhoud hoeven (of willen) bewaren.
Vaak is ook bij een nieuwe firmware download de eeprom content niet compatible met de nieuwe firmware.
Dedicated programmers kunnen dat wel, zoals de pickit2/3 (voor pic).

Je kunt trouwens de eeprom (en de fuses) toch opnieuw programmeren? Gewoon de data in de hexfile opnemen. (tenminste, bij een pic kan dat)

Op 20 januari 2019 14:07:08 schreef Arco:
Ik heb al heeeel veel MCU's geprogrammeerd, maar bijna nooit de eeprom inhoud hoeven (of willen) bewaren.

Nu hebben we het over een persoonlijke voorkeur.

Ik heb al heel veel projecten gedraaid waarbij ik alleen het flash geheugen overschrijf. Ik vind het dan heel prettig als de eeprom blijft staan.
Wij houden er blijkbaar verschillende werkwijzen op na en dat is voor de TS niet van belang.

Dus om op het topic terug te komen.
@TS: Mogen wij de door jou gebruikte fuses zien?
Liefst de verschillen tussen een nieuwe en een gebruikte 2313, want de fuses van een AVR horen NIET te worden overschreven bij herprogrammeren.

Op 20 januari 2019 13:45:17 schreef Arco:
Waarom zouden fuses niet gewist moeten worden? Je weet toch niet of ze bij de volgende programmering hetzelfde moeten blijven staan?

Omdat, als je SPIEN uit zet, je helemaal niet meer kunt programmeren, behalve HVSP. Soortgelijk voor JTAGEN als je via jtag werkt, of omgekeerd met DWEN als je via SPI wilt werken. Of het wijzigen van de clock naar een extern kloksignaal.

Botweg wissen is dus hoogst onhandig, want mogelijk kom je er dan helemaal niet meer in. "terugzetten naar default" zou nog enigszinds redelijk zijn, maar ondoorzichtig als je daar niet expliciet opdracht toe hebt gegeven. Je weet immers niet of je bij de volgende programmering de default fuses nodig hebt...

Rare processors zijn dat dan...
Bij een Pic kun je gewoon alle fuses instellen zoals je wilt (en wat ook logisch is).
Wat is er logischer als alle configuratie instellingen gelijk met de hexfile download in te stellen?

(als je processors gebruikt voor testen heb je tenslotte geen idee wat erin zit van de vorige test?)

Op 20 januari 2019 14:07:08 schreef Arco:
Ik heb al heeeel veel MCU's geprogrammeerd, maar bijna nooit de eeprom inhoud hoeven (of willen) bewaren.

Ik dus wel. Als daar configuratie of calibratie data staat bijvoorbeed.

Vaak is ook bij een nieuwe firmware download de eeprom content niet compatible met de nieuwe firmware.

Wat werk jij met een bagger-programmeurs zeg...

Dedicated programmers kunnen dat wel, zoals de pickit2/3 (voor pic).

Daar heb je bij een AVR geen 'dedicated' programmer voor nodig. Qua hardware kan alles het wat die dingen kan programmeren. Ik ken nog geen programmer die niet alles aan z'on ding kan setten. Maar er zal vast wel een knutsel van iemand zijn die wat gebreken heeft.

Je kunt trouwens de eeprom (en de fuses) toch opnieuw programmeren? Gewoon de data in de hexfile opnemen. (tenminste, bij een pic kan dat)

Natuurlijk staat dat niet in een hex file. Dat is nou precies weer het gezeik met die pic-bagger. Vage memory maps voor dingen die daar in werkelijkheid niet zitten. Atmel heeft dat veel eleganter uit gedacht. En als het dan met alle geweld samen moet, dan douw je het in een elf file.

Waarom zouden fuses niet gewist moeten worden? Je weet toch niet of ze bij de volgende programmering hetzelfde moeten blijven staan?

Natuurlijk erase je die niet! Zeker niet in-circuit. Ze zeggen vaak ook wat over het hardware environment. Dat verandert heus niet bij een firmware update.

Bij een Pic kun je gewoon alle fuses instellen zoals je wilt (en wat ook logisch is).

Dat zo'n pic ding bepaalde functionaliteiten mist die je daardoor ook niet kunt gebruiken, is bekend. Het is tenslotte niet voor niets Prutsen In Chippie...

Wat is er logischer als alle configuratie instellingen gelijk met de hexfile download in te stellen?

Dat is dus helemaal niet logisch. Zeker niet in een hex file waar je die settings op adressen moet gaan zetten die niet bestaan. Immers... Daar zit geen flash of EEPROM. Dus doe dat meer lekker los en als je daar niet mee overweg kunt, dan douw je het in een elf file. Bij nieuwe firmware hoef je nooit de fuses aan te passen. Hoogst zelden de EEPROM - die data wil je meestal juist graag intact laten. Lekker handig... Een compiler die precies moet weten voor welk model er gebouwd wordt. Immers, een ander model heeft een andere memory map en dan moet het dus ergens anders staan. Over 'logisch' gesproken...

Die SPIEN is inderdaad een rare eend in de bijt. Het enige doel is feiltelijk om de nRESET als I/O te kunnen gebruiken. Waarschijnlijk uit de tijd dat 'pincount' nog een issue was. Voor mij is het een soort OTP-idee. Waarbij men dan voor development nog een work-around heeft in HVP.

Voor de TS: je zult zeer specifiek moeten zijn in wat je exact programmeert en hoe. Het lijkt meer op een probleem in de omringende hardware. Of inderdaad een slow start of BOD oid. die verkeerd staat. Geen idee wat die Galep met een 'erase' precies doet. Als die inderdaad ook z'n eigen fuses zet, zoals die Galep denkt dat de 'default' moet zijn, dan zou dat een hoop verklaren.

Op 21 januari 2019 07:05:50 schreef EricP:
Natuurlijk staat dat niet in een hex file. Dat is nou precies weer het gezeik met die pic-bagger.

Niet helemaal waar.
Het is niet een setting die volgens de specs in een intelhex file thuis horen, maar je ziet het wel.

https://www.eevblog.com/forum/microcontrollers/avr-best-practice-regar…