atmega32u2 dooes not leave bootloader

Go To Last Post
12 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have a project I created on a  atmega32u2 breakout board. Works just fine so I'm now moving to my own board. I based the schematic/board off the same design but after I flash my chip with a dfu program tool it remains in bootloader after reset. The HWB pin defaults to high with a pull up but I'm not sure what else would prevent it from running my code. I'm pretty sure both the breakout board and my chip I bought from mouser have the same factory flash and both use a 16MHz clock. I didn't incorporate an ISP to my design but I should be able to wire one up. Any ideas before I do that?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

S_K_U_N_X wrote:
I created on a  atmega32u2 breakout board. Works just fine so I'm now moving to my own board.

Are the fuses set the same between the two boards?   Oh wait, no isp on new board, really?  Was that a good idea?

 

Jim

 

 

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

> The HWB pin defaults to high with a pull up 

 

External pullup?

 

Not a 32U2 expert, but out of the box the only way to get into the bootloader is if the HWB pin is pulled down at (any) reset, or if there is no app (fall through), or an app called the bootloader.

 

Which of course means an external pullup is required to stay out of the bootloader at reset, which I would assume you have.  I think the only other thing that could happen is if you use the reset option in the flip software that uses the watchdog to reset back to the app, and then forget to deal with the watchdog in the app, but that just resets the app and the bootloader is still out of the picture (since there is a HWB pin pullup). In that case your 32U2 is not enumerating as a usb device, so should be easy enough to figure out.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Are the fuses set the same between the two boards?   Oh wait, no isp on new board, really?  Was that a good idea?

 

haha umm no. but I wired up the spi and yes fuses are identical. Everything about the two chips are as it comes from the factory.

 

External pullup?

Yes, used a 1k.

 

Im pretty sure that its not falling to the app but not perfectly clear what to check in the app that does not allow it to fall thru. For example I know the clock is set to 16KHz in my app and my mcu is correct, but what else could I have messed up here?

 

My app uses a watchdog for its own purpose and is reset and set in main.

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Figure it was worth attaching what I have here.

 

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

>but not perfectly clear what to check in the app that does not allow it to fall thru

 

No app is going to let you fall through, but flash that is erased will.

 

You need to figure out where you are at- if the usb enumerates as a dfu device (I assume), you are in the bootloader. If not, you are in the app. That narrows it down.

 

If you are in the app, then create a simple blinky app (voltmeter check a pin I guess, as it looks like no led's)- disable watchdog, 'blink' a pin in a loop. Program it and see if you are 'blinking'.

 

If you are ending up in bootloader, then maybe get to the reset pin (unused it seems) and do an ext reset- if that works (gets you to the app), then maybe power up time causes hwb to read as low when internal reset is released, or something like that.

 

 

edit-

your pin4 Vcc in the schematic seems like a strange way to connect to the pullups- maybe your conversion from schematic to pcb doesn't see that as a connection like you think it is, and the pullups are not actually pulled up. Easy enough to check.

Last Edited: Sun. Dec 6, 2020 - 12:17 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

f the usb enumerates as a dfu device (I assume), you are in the bootloader. 

 

Wow, was I that vague ? :) I seriously suck at explaining things... My fault! Ok, yes by bootloader mode I mean the DFU shows a atmega32u2 in device manager and I can program via command prompt.  The erase works as does the flash. I can reset but I'm back to bootloader again ,meaning that USB atmega32u2 shows up still. I can once again erases and flash. My app is USB code so it should show up on reset but it does not. Yes you are right on my board its pulled up from USB +5 input source. Though yes I checked with a meter.

 

EDIT: Sorry, I did add a reset switch and it does reset just fine, but still in to bootloader.

 

Last Edited: Sun. Dec 6, 2020 - 01:44 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Interesting finding of sorts, I can flash an app I wrote for a 32u4 (a different project). After reset it seems to load but guessing since its a u4 it does pretty much nothing on a u2 chip. But no bootloader... I guess I need to make a hello world u2 test app, still makes no sense to me why my app works on my other breakout boards. There is nothing in my app that force it back to the boot memory page.

Last Edited: Sun. Dec 6, 2020 - 08:01 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 2

Get a JTAG and you could see exactly what is/isn't happening! ;-)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

S_K_U_N_X wrote:
I didn't incorporate an ISP to my design

surprise

 

Take a look at this thread: https://www.avrfreaks.net/forum/how-do-i-check-life-signs-scope-atmega2560-standalone - loads of tips on how to create a "debuggable" design.

 

And, as clawson said, use the JTAG!

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ill have to look in to the JTAG indeed. I used that with my ARM development, was nice.

 

I was able to track down the issue with some poormans debug but the issue points to some strange memory issue ( I think) that the other boards do not have.

 

flashLED(1); <--seen
bridgeInterface->init(); //apparently going to bootloader

flashLED(2);<-not seen

 

because I can do this.

 

flashLED(1); <--seen
//bridgeInterface->init(); //skipped

flashLED(2);<-seen

 

So to break that down a bit, its just a struct.

 

typedef struct {
	void (*init)(void);
    unsigned char (*read)(unsigned char);
	signed char (*write)(unsigned char);
} Bridge_interface;

Bridge_interface bridge = {
    .init					= Init,
    .read					= Read,
    .write					= Write
};

Bridge_interface *getBridgeInterface(void)
{
    return &bridge;
}
void Init(void)
{
	_PORT |= _BOTH;//bring both high to tell slave we are attached.
}

I tried removing the ( _PORT |= _BOTH;) code but something still forces my app to bootloader. I can not figure out why one board does this and the other does not. If I comment out all the Bridge_interface calls, it runs just fine. I'm not even sure a JTAG will help me on this one.

 

Last Edited: Tue. Dec 8, 2020 - 02:56 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Search is over, Looks like I was right, some memory got clobbered.

 

my send command was returning 255 and my array was only 32 bytes.   Later on the jump to my struct was point at the bootloader (presumably). Accessing my stuct before these lines was ok it was accessing after that caused the boot jump.

 

unsigned char returnPayloadSize = sendCommand(0x00);
 for (unsigned char d = 0; d < returnPayloadSize; d++)     returnNrf2Payload[d]=sendCommand(0x00);

 

To fix it I added a simple check before the loop.

if (returnPayloadSize > NRFPayloadMaxSize) return;

 

I guess there is something more to it because I do not see this on my other board but at-least now I have something to work with.