XMC1100 initial programming only async (UART) loader?

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

cross mob
User7804
Level 4
Level 4
Hello All,

is it correct that a brand-new XMC1100 is configured for ASC_BSL, so the only way to get any code into the chip is to feed it with UART data on P0.14/15 or P1.3/2?

No SWD available initially?

BTW: I guess there is also no recovery (erase all) for chips in "user productive mode", correct?

Oliver
0 Likes
6 Replies
Not applicable
Hi Oliver,

You are correct, if the device is fresh from production, ASC_BSL is the only way to get any code into the device.

If you have set the device into User productive mode, basically there is no other mean to access the device.
However, if you have software running in the device that able to change the BMI from user productive mode to other mode, the device will erase all the flash content and install ASC_BSL as new BMI value.
0 Likes
User7804
Level 4
Level 4
Hello Jackson,

will the XMC boot loader and memtool code handle / tolerate receiving an echo of it's transmissions?

Imagine an external single wire transceiver (K-Bus, LIN, CAN) connected to Rx and Tx pins of the XMC. This is not half duplex mode in terms of pin assignment, but it's half duplex in terms of data transfer.

The XMC (and the PC) will receive every byte in turn.

Oliver
0 Likes
Not applicable
Hi Oliver,

I'm not quite understand the situation you were saying.
Is it something like Tx and Rx is shorted at the transceiver?
If that's the case, the echo will be treated as received data by the microcontroller.
Then, the bootloader or memtool are not able to work properly anymore.
0 Likes
User7804
Level 4
Level 4
Hello Jackson,

Jackson wrote:
I'm not quite understand the situation you were saying.
Is it something like Tx and Rx is shorted at the transceiver?


Never heard about LIN, K, CAN? They are not "shorted" but bidirectional, with dominant/recessive status. This means, as soon as one node sets the transmitter to "dominant", all receivers receive the dominant state.

Kind of "wire-OR".

Jackson wrote:
If that's the case, the echo will be treated as received data by the microcontroller.


That's true, data sent by any party will be received by any party.

Then, the bootloader or memtool are not able to work properly anymore.


Are you sure?

This would be a serious flaw since these busses are widespread especially in the automotive environment.

The described basic protocol could handle this as far as I see since there is no demand for full duplex - data flows only in one direction at any time.

IMO it's just a matter of robust implementation. After any transmission, you have to "drain" the received data.

Oliver
0 Likes
Not applicable
Hi Oliver,

It seems to me that this is just a half duplex communication approach (transmit and receive with single pin).
For ASC BSL in XMC1000, it support half duplex mode too.
The full or half duplex selection is select based on the Header Byte received by the MCU.
Please refer to Reference Manual on ASC BSL chapter for more details.
0 Likes
User7804
Level 4
Level 4
Hello Jackson,

Jackson wrote:

It seems to me that this is just a half duplex communication approach (transmit and receive with single pin).


please see my earlier postings about "not single pin at MCU side". Should I explain more detailed how a LIN/K/CAN-Transceiver works?

For ASC BSL in XMC1000, it support half duplex mode too.
The full or half duplex selection is select based on the Header Byte received by the MCU.
Please refer to Reference Manual on ASC BSL chapter for more details.


Well, as I wrote Oct 18th, it's not half duplex over a single MCU pin.

And from what I wrote in earlier postings, it should be clear that I know the documentation somewhat, so please forgive me if I'm not capable understanding it.

Where in the "ASC BSL chapter" do you think my questions are answered?

Oliver
0 Likes