Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problems burning Bootloader onto DB-Series MCU #115

Closed
ProxyPlayerHD opened this issue Jun 6, 2021 · 14 comments
Closed

Problems burning Bootloader onto DB-Series MCU #115

ProxyPlayerHD opened this issue Jun 6, 2021 · 14 comments
Labels
question/support Technical support or question, not defect in core

Comments

@ProxyPlayerHD
Copy link

I recently got my PCBs for my AVR128DB48 Arduino-like Board.

but after assembling one i was unable to burn optiboot onto it.
i used the same exact programmer (jtag2updi using an Arduino Nano) as for my previous board for the AVR128DA48.
here the Error log after trying jtag2updi: PASTE

both boards are almost identical, only noticable differences are the MCU itself (DB/DA) and the DB Board having the same reset circuit as regular Arduino Boards while the DA Board's Reset is only controlled by a push-button.
here an image of the Schematic in case the mnistake is hardware related:
eeschema_2021-06-06_18-32-20

i also tried the other method, Serial UPDI, only using a resistor because i have no compatible diodes at home. the UART/USB Module i used is called "SH-U09" which has the CP2102 Chip on it.
either way it didn't work either, here it's Error Log: PASTE

i'm really not sure why this won't work...

@SpenceKonde
Copy link
Owner

SpenceKonde commented Jun 6, 2021

I don't suppose you have the push button the wrong way around do ya, with the 2 pins that are connected to eachother going to the two sides of the circuit, instead of pins that are only connected when pressed. That happens all the time with those buttons, and I notice your part library doesn't even make explicit which pins are which. If reset is held low, you can't program them. Check that reset isn't being held low.

I also will note that DB parts were always slightly pricklier to program with jtag2updi, and I could never figure out why (the sort of thing where it would eventually work, after powercycling and resetting programmer and target a few times). That was one of the reasons I gave up on jtag2updi (do note that it is no longer the recommended programming method - it's unreliable garbage written in a manner actively hostile to someone who might improve it (I learned that the hard way) and always was, but now we have something else that isn't garbage and that WE CAN FIX, unlike jtag2updi, where you need to be able to crosscompile avrdude for what, 6 platforms? to do a release that fixes a bug- and then you'd be known as a person who knows how to modify avrdude, and which point you're a marked man - you'd have to wear a disguise to go to the pharmacy lest someone see you and ask when you're going to fix one of the other several thousand open bugs that they care about...

@SpenceKonde SpenceKonde added the question/support Technical support or question, not defect in core label Jun 6, 2021
@ProxyPlayerHD
Copy link
Author

the Button is correctly wired, using my Logic probe i can see that the Reset pin is high by default and pressing the button pulls it low.

also when programming with Serial UPDI i just had the resistor on a breadboard, could that cause issues? i also selected the lowest baudrate to maybe minimize the amount of noise you get from breadboards

@SpenceKonde
Copy link
Owner

SpenceKonde commented Jun 6, 2021

I've got no solutions, other than to note that I did see that failure mode when reset was being mishandled. I think in my case it was a solder bridge between reset and updi, rather than it being shorted high or low.

It's always been a wiring problem when I had issues where one persistently refused to program (meaning assembly problem because schematic is correct as drawn.)

Shouldn't be a problem on breadboard, 230400 baud isn't fast enough for breadboard to act badly.

@ProxyPlayerHD
Copy link
Author

i also checked the Resistance between the UPDI Pin and various other things on the board, it only has direct continuity with PD7 and PB3 (and of course the Programming Header)

and no it doesn't seem to be a mistake on the PCB that PD7, PB3, and UDPI are connected as i checked those same pins on my second, unsoldered/untouched AVR128DB48 i still have lying around, and aparently that is just a thing this MCU does for some reason...

I'm thinking about ordering some 1N4148 Diodes and seing if i can get the ideal Serial-UDPI circuit set up.
if that still won't work then i'll just design a custom PCB for the Serial-UPDI Programmer (shouldn't be hard, it's just an FT232, a Diode and a Resistor, just all in one neat package)
and if that still won#t work, then i'll just stick with the Raspberry Pico and my STM32 board until i come up with a solution.

@SpenceKonde
Copy link
Owner

SpenceKonde commented Jun 6, 2021 via email

@SpenceKonde
Copy link
Owner

SpenceKonde commented Jun 6, 2021

And, euhm... I measure 800kOhm to 1.5 meg between UPDI and PD7 and PB3 on my parts... both DB48 and DB64. And between PD7 and UPDI.

Sure it's not PC3? Because then you'd be measuring between the three supply pins, which are each 1 pin beyond the one you mentioned.... and the only mystery would be why the VDDIO2 was shorted to supply... and if it was mounted on a PCB with single supply, that would be expected. Hopefully (for your sake) that this was a fumbled measurementm and you didn't either get a bunch of boards fabbed with the pinout off-by-one, or end up with something you can't assemble with acceptable yield due to the part ending up with each pin between a two pads instead of properly centered (only way I've ever reworked that successfully is to remove the chip and throw it out, and then drag solder on a new one - I think my yield is only in low to mid 80's (and that's after I rework the "easy" stuff like bridges for the 64's... though it's much higher on the 48's = those can be slightly more cockeyed and still fix themselves in the reflow oven.

@ProxyPlayerHD
Copy link
Author

ProxyPlayerHD commented Jun 7, 2021

the pinout is correct, i made the PCB Footprint myself using the offical datasheet (i still rechecked it to make sure).
and rechecking the "shorts" it's between pin 7 (PB3), 27 (PD7), and 41 (UPDI). no other pins have any shorts between eachother.
and again this cannot be related to the PCB at all as i'm getting the same results from my completely untouched AVR128DB48 as well. (i ordered 2 of them but only soldered one of them)

can it be that i got some dead ICs that have some internal shorts? it seems very unlikely but i cannot really think of any other reason why you can't measure the same shorts

@SpenceKonde
Copy link
Owner

I would say it is inconceivable that they would ship product that badly broken -even though this is the company who shipped the AVR32DA to customers without having even tested any of them with the equivalent of blink (and hushed up the whole thing) - but that's a systematic testing failure, a hole in their testing coverage (albeit one large enough to drive a truck through), and it's no secret that they have a lot of those (as documented in the errata). They're going to do tests for shorted pins when they do the factory oscillator and temp calibration. In fact, I'm pretty sure they do that using UPDI with a special factory-calibration key.

Hmmm. I looked at the pinout chart again. It wouldn't make sense if those were shorted together on the 48-pin package - it doesn't line up with any power/ground pins...

Unless....

you're mistaking the orientation markings, and have the chip rotated 90 degrees from the right way around? In that case, what you thought was pin 7 (PB3) would be pin 43 (ground), what you thought was pin 41 (updi) would be pin 29 (ground), and what you thought was pin 27 (PD7) would be pin 15 (ground). That is just so much more likely than a batch of bad chips...

@ProxyPlayerHD
Copy link
Author

ProxyPlayerHD commented Jun 8, 2021

bruh.

i just saw the fucking dot on the Chip.

for some reason i didn't look at it while soldering and thought that the text on the chip had to be right side up for pin 1 to match, but that was wrong. Pin 1 of the IC is on Pin 13 on the PCB.

i measured the same pins on the unsoldered one... which was also rotated, that's why it had the same results...

i'm dumb

this is exactly why i always buy multiple chips in case i fuck one up.

i'll solder a new board and maybe attempt to save the one i already have. but desoldering is pretty hard if only have a regular soldering iron

@SpenceKonde
Copy link
Owner

SpenceKonde commented Jun 8, 2021

AFAIK there's no standard for wjhich corner the dot goes in vis-a-vis the text/

I've assembled probably half a dozen boards with the chip backwards? It's up there on the list of "ways I've fucked up that have happened more than once", and certainly my top "unforced" error. Like, if I do a lousy job with the solder paste, and make a mess of bridges, or if the placement is poor and they come out cockeyed, that's poor technique, and my fault, yes, but it's in a different category than putting chips on backwards. I don't think I've done that with a QFP actually, always SOIC-14's because the only orientation guidance is direction of the text that is supposedly on the top of the chip (I literally cannot read it, or even approximate reading closely enough to see which way is up, under normal conditions, and I am young and have good eyesight) and an almost invisible rounding on one edge. I really wish they used a dot instead of that rounded edge.

Our of a fraction of the sample size though, I have managed to put on about as many 64-pin Dx-series parts cockeyed or one-row-of-pins off. . Only way I've ever fixed one is to heat-gun the chip off, throw it in the trash (it's always mangled by then) and drag solder on a new one. Some time I'm gonna try running one through a reflow cycle, opening the oven at the end, and then nudging the chip into position....

But yeah, considering my experience reworking cockeyed DA64's, faced with a wrong-angle DA48 (same fine pitch) chip, I would write off the chip itself, and only attempt to salvage the rest of the loaded boards if the effort it would save soldering the rest of the parts in was worth it. IMO the iron is going to be useless. IMO, you'll spend so much time on it that you could ha ve earned enough to buy a dozen of them working sy minimum wage, and I'd predict you'd end up lifting pads on the PCB by the time the chip was off. the methods that could plausibly work. If all I had that was made for soldering was an iron, I'd use a butane torch before I'd try to take that off with an iron (and as you might guess, the torch is WAY too aggressive and trashes things very quiickly - at least then you waste at most a minute on it, instead of a few hours).

@ProxyPlayerHD
Copy link
Author

ProxyPlayerHD commented Jun 8, 2021

i'm still having problems...

i made a new board, and damn that is the most perfect SMD soldering job i've ever made:
oenWdsR

anyways, Serial-UPDI still didn't work, i used a 2.2k resistor instead of a diode.
here the error log: PASTE
jtag2updi seems to have worked but i cannot upload sketches via USB, here jtag2updi's log: PASTE
and the error i get when trying to upload Blink via arduino's "upload" button: PASTE

@SpenceKonde
Copy link
Owner

So serialupdi with unspecified hardware and an incorrect-value resistor instead of the recommended schottky diode didn't work. Is this surprising? I can't help further on that without knowing what serial adapter (or chip model + resistance between tx pin of chip and tx pin coming out of the board (a picture is probably sufficient here, most of them are pretty recognizable, and I've tried to buy at least one each of the common models that are making the rounds these days), as well as confirmation of where the resistor was connected (unless the adapter board has an internal 2.2k resistor too, which it at the high end of the range I would expect a high risk of it not working with an external 2.2 even with otherwise correct topology. My experience has been that when using the resistor, the range of values of resistors in various places in the that it will work with which operating voltages is quite narrow. I always had a hard time making the resistor method work, it wasn't until two people suggested the diode within days of each other, I did the math, realized a decent schottky diode would bring us well into friendly territory, and wired that up, and it performed flawlessly. Of course some other people are swearing that it's the other way around, so more study is clearly needed. If I saw a scope trace capture (signal mode, trigger on UPDI rising or falling) I suspect the problem would be immediately apparent to me.

Anyway, the jtag2updi that succeeds show's a burn bootloader operation with the (no bootloader) option selected. That just sets fuses, and erases anything in the flash. including any bootloader, as it should because you['re preparing the chip for use without a bootloader) in the flash. But the second one shows you trying to upload through the serial port with a different board definition selected; You would need to burn bootloader with the optibootboard def selected if you want the bootloader to be installed.

Finally, even once those things are corrected, it would appear that you have TX of the serial adapter connected top PA0. which is TX of USART0 in default pins. Serial gets wired TX (transmit) to (receive) in each direction.

And a third point, you're using an avr DB aren't you:? Why are you using the default serial0 pins at all? Are you not planning to use an external high frequency crystal, and just rely on the internal oscillator?

@ProxyPlayerHD
Copy link
Author

i'm sorry but i said the exact module and chip it had on it on the first post in this issue. to quote:

the UART/USB Module i used is called "SH-U09" which has the CP2102 Chip on it.

here a high res image of the top of the module:
CxXQRx1

I always had a hard time making the resistor method work, it wasn't until two people suggested the diode within days of each other, I did the math, realized a decent schottky diode would bring us well into friendly territory, and wired that up, and it performed flawlessly.

problem is that i don't have any schottky diodes and don't really know which ones are useable for this (the only one you mention in the wiki here is an SMD Part and i'd rather have something TH so i didn't have to solder some leads onto a small SMD Diode)
do you have some TH Diode Recommendations?

If I saw a scope trace capture (signal mode, trigger on UPDI rising or falling) I suspect the problem would be immediately apparent to me.

i still don't have an oscilloscope, i really need to buy one but i'm hesitant because it's a lot of money. probably just gonna bite the sour apple and get myself a Rigol DS1054Z.

Anyway, the jtag2updi that succeeds show's a burn bootloader operation with the (no bootloader) option selected. That just sets fuses, and erases anything in the flash. including any bootloader, as it should because you['re preparing the chip for use without a bootloader) in the flash. But the second one shows you trying to upload through the serial port with a different board definition selected; You would need to burn bootloader with the optibootboard def selected if you want the bootloader to be installed.

so basically i just misunderstood what the different options meant? that sounds very much like me.
i thought you select the board (without optiboot) to tell the IDE that the board has no bootloader and that you want to burn it onto the board, and afterwards you would switch to the board (with optiboot) to program it normally via USB.

i now used JTAG2UPDI while having the board (with optiboot) selected, burned the bootloader and it works now.

Finally, even once those things are corrected, it would appear that you have TX of the serial adapter connected top PA0. which is TX of USART0 in default pins. Serial gets wired TX (transmit) to (receive) in each direction.

what exactly do you mean? in the schematic FT232RL's TX is connected to PA1 not PA0. it's the same connection i had on my DA Board so i know it works.

And a third point, you're using an avr DB aren't you:? Why are you using the default serial0 pins at all? Are you not planning to use an external high frequency crystal, and just rely on the internal oscillator?

yea pretty much, the reason i'm even using the DA/DB Series Chips is because of their high speed internal oscillator (and the amount of Flash/RAM). it saves me PCB Space and an extra component, and i never saw a point in having an external oscillator unless you want to do some very very precisely timed things.

@SpenceKonde
Copy link
Owner

I've had a wonderful time with my Siglent SDS1202 - Seems I live in a Siglent family. Didn't stop using my Siglent SDS1202 until this christmas, when my father got us both shiny new SDS2204X'w with the touchscreen and every feature (had to buy something nice during the pandemic, but we were all afraid to go out to christmas shopping)

Yeah - you're the second person to have this misunderstanding... but here's the weird part - The otyher person was just a couple of months ago. And I've maintained cores for like 5 years. What changed in how people view those options, I wonder?

I wish there were some way to put a notice where people would see it to tell them to set the bootloader options for what you want, and then "burn bootloader" to make the chip match what you've selected. "dress for the settings you want, not the settingsyou have" :-P

,my bad on the schematic, I somehow read them backwards..

Can't argue with that -. the internal oscillator on the Dx-series certainly is a nice piece of hardware. Can crank it to 32 no problem at room temp! And the PLL will work at 4x muiltiplier on that too. These things arte spec'ed with an incredible amount of headroom (of course they asre, some are speced hot enough to be used at temperatures in excess of boiling point of water.... I wouldn't mind the internal oscillator if the cal setting had finer granularity, but like it's around half a percent per increment or something like that, which kinda take the point out of autotune, you know? I don't know what all happened with the modern AVRs, but we losrt the two MSB, of OSCCAL:, and only the 2 series have gotten one of those back (they have an AWESOME internal oscillator, some are stable at room temp all the way up at 32! (and even 1-series did 32 off ecxternal clock, if you were a nice healrthy 5v, but died not far below that voltage)

I had a Dx doing 40 off ext clock no problem but it wouldn't do 48 :-/ And you can't nudge the voltage up to the very upper edge of the range to try to make it work, because the voltage gets regulated down anyway. Not that I have any particular need for a 48 MHz AVR, but because I can, I got some of the high temp spec ones to try, just in case those go a little higher . Alsi planning to try crystal @ 40 MHz for the hell of it. :-P

I do like having a real crystal for the timebase, personally - not that I always or even usually need it, but fo a serious business board, where I have plenty of pins for it, I always want to puit one in :-P

IMO if you're doing anything demanding on an AVR, you'd be nuts to not use a Dx-series - what else would you use, a mega2560 classic running at half the speed, with store, push cbi and spi each running twice as long, and periherals that were stale a decade ago? If they hadn't come out with something soon, AVR was not going to rekmain a viable architecture. Especially not with the prices they charged for cl;assic AVRs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question/support Technical support or question, not defect in core
Projects
None yet
Development

No branches or pull requests

2 participants