Hello, I'm working on a board as follows: own design with at32uc3c2256, Ethernet PHY TI/National DP83484I, 3.3 Volt supply local from DC/DC converter, a few gpio pins, PWM, TWI, no use of ADC/DAC, but analog power supply connected to 3.3 V and bypassed, as recommended. The master clock is external osc. 25 MHz, obtained by dividing the 50 MHz PHY clock by two. The software uses FreeRTOS and the lwip stack from AVR Studio 6 ASF libs. We build five prototype boards, six layer pcb according to Atmel and TI design recommendations. After fixing some minor hardware and software bugs, two of the five boards work pretty well, including Ethernet operation, after flashing and starting via JTAG, as well as powered up stand allone. But the boards no. 3 to 5 show a strange behaviour: They work perfectly, including ethernet, if flashed and started via the JTAGICE3 debugger by means of the AVR studio. After booting the target, I even can quit the debugger, pull the JTAG connector off and the board continues to run. But if I start the board without JTAG, the CPU seems not to run at all. The PHY works, lights its 'link' LED when connecting the Ethernet cable, even the 'activity' LED flashes if I try a ping to the target's address. But the CPU seems not to execute a single line of code. I placed a couple of bit toggles onto some unused gpio pins, they work perfecty when starting the target via the studio, but I can't measure a single edge there if the target was powered up stand allone. All voltages and (external) clocks are ok, the same as when the board runs. The debugger doesn't help much, because the system runs pretty well when JTAG connected and started by the studio. If I press the reset button after quitting the debug session in the studio, while still having JTAG connected, the target resets, but does not start again, so the pure electric connection to the JTAGICE3 seems not to play a role. Any ideas about troubleshooting strategies? How can I reset the target without flashing and without the unconditional stop in the first line of 'main.c'? Horst
Hello again, it's always the simple things which cause the worst headaches! I found it by myself, here for all the others, trapping into the same hole: After a hardware reset, the hardware watchdog may be enabled, depending on the fuse settings. In the software, the first thing we coded, was to disable the watchdog by calling the ASF driver function "wdt_disable()", which resets the enable bit in the AVR32_WDT control register. But this function has never been called because the watchdog time setting was far too short for reaching that function call. When flashing these chips the first time, don't forget to disable the watchdog in the WDTDISRV fuse bit first, otherwise the processor may run into an infinite loop by permanently resetting itself. The JTAG debugger broke this loop by intervening via hardware and when starting the user code at main(), the driver function was called at first, seemingly solving the problem, so that it was impossible to find the bug by means of the debugger only. Horst
Hi hBechtold, thanks for telling us your solution. We had the same Problem! Bruno
Hi Horst You just saved me hours (maybe days) of struggle, as first google result was your post. Just so you know - there is one person on planet who'll be always grateful for this post. All the best Alen
Watch this topic
Disable multi-page viewPlease log in before posting. Registration is free and takes only a minute.
Existing account
Do you have a Google/GoogleMail account? No registration required!
Log in with Google account
Log in with Google account
No account? Register here.