4
\$\begingroup\$

I'm trying to make my Atmel at91sam3u cortex-m3 arm chip make an LED blink. I have a Olimex ARM-USB-OCD-H jtag programmer, and I'm using Open OCD running on OS X to program my chip. I'm using the provided Open OCD startup scripts for the jtag programmer and my chip. I have no trouble compiling and linking the program, and I seem to be able to successfully load the program on the chip. However, the LED only blinks when I run the program via gdb. It works whether I step through it or run it continuously.

To make it work in gdb, I first run 'openocd' and then in another terminal (gdb feedback ommitted):

$ arm-none-eabi-gdb blinky/blinky.elf
(gdb) target remote :3333
(gdb) load
(gdb) cont

This works without any issues and the LED blinks. Ofcourse, when I exit gdb, the program is stopped, and the LED is left in whatever state it was at that time. If I click the chip's reset button the LED goes to a neutral (slightly on) state.

To try to simply program the chip, I run 'openocd' and then in another terminal:

$ telnet localhost 4444
> halt
target state: halted
target halted due to debug-request, current mod
xPSR: 0x81000000 pc: 0x00080107 msp: 0x20000598
> flash write_image blinky/blinky.elf
wrote 3044 bytes from file blinky/blinky.elf in 0.314594s (9.449 KiB/s)
> reset run
TAG tap: sam3.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)

There are no errors, but the LED does not blink, it stays in a neutral state.

The linker script sets the program (.text) to be put in flash0 memory. Thus I've tried setting gpnvm bit 1 as that is the sram vs flash boot select bit according to the at91sam3 datasheet. This did not help, and it seemed to have prevented gdb form running properly.

Do I need to maybe flash the board with some sort of bootloader that can load programs from the flash0 bank? I assumed that the chip came with this.

I have not yet been able to load the .text into sram instead of flash0 as I've had trouble changing the linker script I have to do this.

Note: The at91sam3u chip is on a custom pcb designed as part of a student design project. Thus, it is possible that a mistake was made during the pcb design... however, I would think that in that case it would not run properly in gdb either.

Thank you.

\$\endgroup\$
2
  • 1
    \$\begingroup\$ I had this problem a while ago with IAR and a SAM7X. In that case, it turned out the debugger was doing what the startup code should have, and hence it wouldn't work by itself. Id look at the startup section for anything missing. The SAM3U has a much simpler startup sequence code wise, so perhaps check the clock initialiazation and PMC stuff, and more importantly things like the interrupt and reset vectors. \$\endgroup\$
    – Chintalagiri Shashank
    Jan 26, 2013 at 15:08
  • \$\begingroup\$ You've produced a HeisenBug! It's a software bug that does away when you try to observe it. \$\endgroup\$
    – Connor Wolf
    Mar 24, 2013 at 3:35

3 Answers 3

Reset to default
4
\$\begingroup\$ 
$ telnet localhost 4444
> halt
target state: halted
target halted due to debug-request, current mod
xPSR: 0x81000000 pc: 0x00080107 msp: 0x20000598
> flash write_image blinky/blinky.elf

You usually need reset init before a flash erase/write, halt may not be enough. In gdb it is monitor reset init.

The flash also needs to be erased before writing: flash write_image erase unlock blinky/blinky.elf

\$\endgroup\$
2
  • \$\begingroup\$ Hmm, when I do a reset init in gdb or via telnet, I get this: (gdb) monitor reset JTAG tap: sam3.cpu ... \ Halt timed out, wake up GDB \ timed out while waiting for target halted \ TARGET: sam3.cpu - Not halted \ in procedure 'reset' individually though, the commands work fine... I'm not sure if this is a problem, or just the reset init happening too fast. \$\endgroup\$
    – Stepan
    Dec 23, 2012 at 16:24
  • \$\begingroup\$ This happens to me when reset_config does not match the actual wireing of the reset line(s). You can try reset_config none. \$\endgroup\$
    – Turbo J
    Dec 23, 2012 at 18:51
2
\$\begingroup\$

You gave a pretty big clue when you said that the LED was in a "neutral" state. There is no "neutral" state for a properly functioning digital output, so you probably meant that the LED is dimly lit. And that usually means that the pin driving the LED is being turned on and off so fast that you can't see the blinking. You didn't show your code so we can't judge your delay loop, and it's possible that your debugger slowed the code execution enough that it appeared to work.

Another thing to consider is that the JTAG debugger may have taken control of the RESET input. If that's the case then you will need to disconnect the debugger to see "normal" operation. I'm assuming that you have written the proper values for the initial stack pointer and PC value at locations 0x0 and 0x4, of course.

\$\endgroup\$
1
  • \$\begingroup\$ I thought the same thing about my delay loop... but when I make a program that simply leave the LED on or off, the result is the same. It works properly in gdb, but not without. As for the stack pointer and PC - my vector_table.c is the same as the one Atmel provides for this chip in their getting started manual and as far as I've been able to understand it they are set properly. Also, I assume that the program would not run properly in gdb otherwise either, no? \$\endgroup\$
    – Stepan
    Dec 23, 2012 at 16:32
1
\$\begingroup\$

Although the debugging session has stopped, it might be happen that your hardware debugger still has the RESET's signal control.

An inelegant workaround is to detach the debugger from your target, and to apply a cold-reset (power supply off and then on).

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.