we have a custom board based on an AT91SAM9G20-EK but with less RAM and this connected with 16 bit instead of 32 bit. USB and DBGU circuitry are the same as on the EK board. Based on SAM-BA v2.16 we could successfully build our own applets. This works fine so far in SAM-BA GUI itself with our recompiled applets. I can connect and work via USB and see debug output on DBGU (serial console).

Now we wrote a custom tool for testing and flashing the board, based on the examples coming with SAM-BA, especially the one for VS6 without MFC. After having trouble with our application, I verified the odd behavior with all three examples, so I'm sure it's not my fault, but a bug in sam-ba.dll or the USB driver for the CPU. What happens is this:

Now this call hangs exactly every second time. No matter if started as Debug from Visual Studio 6 or starting the compiled .exe file. One call succeeds, for the next one execution hangs somewhere inside sam-ba.dll (at least this is what the call trace in VS6 shows), the next call succeeds, and so on.

This does not happen if I connect over serial, e.g. COM1.

Can anyone reproduce this? Is this a known bug? Has anyone a solution? Will Atmel fix this?

I did not try (yet) with older SAM-BA releases. Is there a chance v2.15 or earlier don't have this bug?

presssaft wrote:we have a custom board based on an AT91SAM9G20-EK but with less RAM and this connected with 16 bit instead of 32 bit.

So how thoroughly has your board been checked out?
Have you ever used a memory test/exerciser like the one in U-Boot?

The board is quite mature, we started developing it in 2010 and meanwhile it reached hardware revision 3.2. Additionally to the short RAM test of the extram SAM-BA applet shipped by Atmel we have a custom RAM test as a SAM-BA applet based on http://www.barrgroup.com/Embedded-Syste ... st-Suite-C – We tested several boards and those are used in production with U-Boot and Linux for years now, I'm pretty sure the RAM is okay.

As I said, there are no problems connecting over serial (DBGU), the problem is over USB only and always when calling AT91Boot_Open() from my application. On one attempt it hangs, on the other everything is working fine. We can successfully test the RAM and the NAND flash over USB, the bootloader(s) written to NAND flash actually boot.

Maybe interesting: with SAM-BA itself (not our application accessing sam-ba.dll) the connection over USB is always successful, which is weird, because in the AT09423 application note it looks like SAM-BA itself also accesses the target through this library.

I'll try a different board with a completely different layout but the same CPU, but have to wait for my colleague first.

blue_z wrote:And to eliminate the obvious:
You're aware of the errata, and booting with the 32 kHz external oscillator?

I was not aware of the errata, but I double checked now. We have the 32.768 kHz crystal and OSCSEL is connected to VDDBU through a 100k series resistor. Multimeter shows 1.04V on VDDBU and 1.03V on OSCSEL. According to datasheet this has to be somewhere between 0.9V and 1.1V.

The device is reliably detected as USB device and always shows up correctly in Windows device manager or with lsusb on Linux. It is connected through a USB 2.0 port and we tried different host PCs, same symptoms on both.

Meanwhile I checked the other board from my colleague and it also boots with the crystal and according to schematic OSCSEL is connected to VDDBU, I did not measure the voltages though. Those boards have been flashed with SAM-BA GUI (or script) over USB for years, however with the new application linking sam-ba.dll or even the examples coming with sam-ba v2.16 it hangs on every second call to at91boot_open().

FWIW we are compiling with MS Visual Studio 6 on Windows XP (on a virtual machine with airgap), both with latest service packs.

This looks to me like a workaround. The port is opened, some options set, three bytes send, queues cleared and so on, the port closed again and then reopened for starting …

Now the documentation says, just call AT91Boot_Scan() and AT91Boot_Open() and you can work with the device. No word about scan, fake open the port, clear everything, close the port, and then really open it.

presssaft wrote:
This looks to me like a workaround. The port is opened, some options set, three bytes send, queues cleared and so on, the port closed again and then reopened for starting …

Now the documentation says, just call AT91Boot_Scan() and AT91Boot_Open() and you can work with the device. No word about scan, fake open the port, clear everything, close the port, and then really open it.

We actually implemented a workaround now, too. If anyone needs this, pass the string you got from AT91Boot_Scan() as dev_name and call the below stuff before AT91Boot_Open():