ASC bootstrap loader for XMC1100

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
User16189
Level 1
Level 1
Hi,

Before integrating a bunch of XMCs on my PCB, I would like to know whether I can flash them via a serial interface.
I have a host running Linux on the same PCB, which I would like to use to program the XMCs.

Memtool is only supported for Windows, so I am on my own unfortunately.
I studied APP note AP32277, ASC Bootstrap loader for XMC1000.
The host part of the provided example code is also pretty Windows based.

To test, I cross connected TX and RD (+GND) from the Linux host to the cute XMC1100 2Go development board using pins 0.14 and 0.15
The BMI of the XMC1100 is set to ASC bootmode with DAVE4 and the dev board is rebooted.
The host sends with 19200 baud, 1 stop bit and no parity.

After sending the two bytes '0x00' and '0x6C', I would expect byte '0x5D' as acknowledgement.
However, this does not occur.

When I send these two bytes multiple times, two situations occur:

1. The XMC1100 does not answer
2. The XMC1100 sends 0x02 after receiving the 0x00 byte.

These situations alternate each other (first one, then the other, and so on).

The first situation (no answer) can indicate that the transmission/protocol is not correct (I checked transmission/reception with a scope and I can see the bytes).
Although I have no idea what could be wrong.

The second situation is very strange, as 0x02 should be only sent by the XMC after an invalid length of the hex file.
This should never happen, because if the header byte is not received correctly, it will again listen for a new header byte.
Maybe also a problem in reception/protocol?

Any idea what could be wrong or how to debug?

Can it be that the XMC4200 debug IC on the 2Go board interferes this proces?
I would expect that if this is the case, the XMC1100 would not answer at all.

This seems so simple, but it doesn't work...

Any help appreciated.
0 Likes
3 Replies
User16189
Level 1
Level 1
Attached is an image of the scope, which clearly shows that 0x00 and 0x6C are sent to the XMC1100 by the master at 19200 baud (52 us/symbol), with start and stop bits and lsb first for data bytes.

Does anybody now why the XMC1100 does not response properly to this sequence?

3422.attach
0 Likes
jferreira
Employee
Employee
10 sign-ins 5 sign-ins First like received
0 Likes
User16189
Level 1
Level 1
Hi,

Given the sharp edges on the scope, I do not think that a pull up resistor will help. However, it doesn't hurt either, so I added a 10k resistor between P0.14 and Vdd. As expected, it doesn't solve the issue.

Next, I tried to double check the BMI with DAVE4. Immediately (without timeouts), it says that it can not read/get the BMI.

3424.attach

I do not understand why, but as the BMI can not be read, this could be the problem. A hardware problem? I do not completely trust the hardware anymore.

Therefore, I proceeded with a brandnew 2Go board. Luckily, they are cheap.
The same setup could change the BMI of the new board to ASC BSL. So the problem was something with the old board. Not the DAVE4 / Segger setup.

Sending the zero and the header byte resulted in a BSL_ID (0x5D) response. That's good!
Next, the host transmits the 4 length bytes, resulting in an BSL_OK (0x01) response.
Next, the host transmits the application program stream. Then the XMC1100 remains silent (again). No response.
Hmmm.
Maybe, something went wrong, so I would like to repeat the handshake protocol from the start.
Disconnecting the USB cable for 1 minute and powering up the board does not work.
The XMC1100 does not respond anymore.
It looks like the handshake protocol keeps state between reboots.
This would also explain the alternating behaviour in the first situation and the response of 0x02.
Because it does not expect the zero and header bytes (as I would think), but the length. After 4 bytes received, it will respond.

Also, DAVE4 is not able to change the BMI of the new board. Same error as before.
I would like to do this, hoping that this would reset the handshake protocol.

So, new questions arise:
- is there a state kept in the handshake protocol between reboots? (Sounds unlikely to me, but behaviour looks into that direction)
- how to hard reset the XMC1100 device? So that I can start with the handshake protocol from the beginning.
- why is it impossible to get/set the BMI header after an unsuccessful ASC BSL handshake protocol? Note: The problem remains also after reboot.

It feels like stirring in a black box. Not a good feeling. And definitely time consuming.

Hope that somebody can explain this behaviour?
0 Likes