PDA

View Full Version : XMC1100 initial programming only async (UART) loader?



obetz
Oct 10th, 2013, 02:37 AM
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

Jackson
Oct 17th, 2013, 01:42 AM
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.

obetz
Oct 18th, 2013, 02:10 AM
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

Jackson
Oct 22nd, 2013, 01:06 AM
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.

obetz
Oct 23rd, 2013, 02:45 AM
Hello Jackson,


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


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

Jackson
Oct 23rd, 2013, 11:09 PM
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.

obetz
Oct 24th, 2013, 07:44 AM
Hello Jackson,



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