infineon4engineers Facebook

infineon@google+ Google+

infineon@linkedin linkedin

infineon4engi@twitter twitter

infineon@youtube youtube

+ Reply to Thread
Results 1 to 4 of 4

Thread: ASC bootstrap loader for XMC1100

  1. #1
    Beginner Beginner ltsmit is on a distinguished road
    Join Date
    Dec 2018

    ASC bootstrap loader for XMC1100


    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.

  2. #2
    Beginner Beginner ltsmit is on a distinguished road
    Join Date
    Dec 2018
    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?

    Click image for larger version

Name:	190207_scope.jpg
Views:	2
Size:	381.5 KB
ID:	3794

  3. #3

    Infineon Employee
    Infineon Employee
    jferreira will become famous soon enough
    Join Date
    Oct 2012

    Did you check ?

    The views expressed here are my personal opinions, have not been reviewed or authorized by Infineon and do not necessarily represent the views of Infineon.

  4. #4
    Beginner Beginner ltsmit is on a distinguished road
    Join Date
    Dec 2018

    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.

    Click image for larger version

Name:	bmi.PNG
Views:	0
Size:	55.4 KB
ID:	3796

    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.
    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?

+ Reply to Thread

All content and materials on this site are provided “as is“. Infineon makes no warranties or representations with regard to this content and these materials of any kind, whether express or implied, including without limitation, warranties or representations of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. No license, whether express or implied, is granted by Infineon. Use of the information on this site may require a license from a third party, or a license from Infineon.

Infineon accepts no liability for the content and materials on this site being accurate, complete or up- to-date or for the contents of external links. Infineon distances itself expressly from the contents of the linked pages, over the structure of which Infineon has no control.

Content on this site may contain or be subject to specific guidelines or limitations on use. All postings and use of the content on this site are subject to the Usage Terms of the site; third parties using this content agree to abide by any limitations or guidelines and to comply with the Usage Terms of this site. Infineon reserves the right to make corrections, deletions, modifications, enhancements, improvements and other changes to the content and materials, its products, programs and services at any time or to move or discontinue any content, products, programs, or services without notice.