Error in ISP of LPC812: Lost characters when sending bytes too fast to LPC812 with command 'W'

lpcware · ‎06-15-2016

Content originally posted in LPCWare by capiman on Fri Jun 28 04:38:12 MST 2013

I use ISP to program a LPC812. Baudrate is 115200. Echo in ISP is on.

According to user manual no XON/XOFF is used and also no other flow control. Also i have not seen a baudrate limit for ISP.

I send a command 'W' with length 1024. Then i send 1024 bytes of data in one go (WriteFile from Windows over FTDI 2.8.28).

The number of echoed characters is sometimes less than 1024 (e.g. 1020). When looking into the received data stream and comparing the data with the sent data, i see that some bytes are missing. There a different bytes missing, so i assume it is not because of the content of the data.

What is perhaps interesting, is, that the time the LPC812 needs to answer on a received byte, seems to be increasing. Why? Some time, when the time is too big, a character gets lost, so time is reduced, till the time is small enough again. It starts with 100 us, and when error occurs the delay by LPC812 is already up to a value of 326 us...

When i reduce the number of bytes to 4 x 256 bytes, it seems the error does not occur, or at least rate of occurance is reduced.

(this gives LPC812 time to get breath again)

BTW: I use a LPCXpresso with LPC812 on it, bootloader version 13.1

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Helmut Stettmaier on Mon Apr 27 09:25:28 MST 2015
Hello,
I had the same and similar problems and the question is apparently still open.
PartID=0x8120, BootCodeVersion= 4.13

During sending the binary data the echo was shorter than what was sent and the OK acknowledge, as promised in UM 22.5.1.4, never was received.

I use smaller chunks to be downloaded (32 Bytes), make a code independant of the "OK" (reading, but not going into panic when it isn't sent) and -->avoid to write something below address 0x10000400 (CRP is -->not active).
This helps.
Baud rate is 9600, the full data block is 1KBytes (1 page), to be sent to 0x10000400..0x100004FF, I do a re-read and comparison is ok. I use Win81 serial com with an FTDI converter.

Kind regards,
Helmut

lpcware · ‎06-15-2016

Content originally posted in LPCWare by ajsndd on Thu Nov 27 05:23:03 MST 2014
Hi Ken,

Is this problem still exists ?
We are also facing issues with UART data missing for large data transfer in some LPC812s.

This issue have been found only in some LPC812s after few days working.

Thanks

lpcware · ‎06-15-2016

Content originally posted in LPCWare by usb10185 on Thu Sep 05 08:58:04 MST 2013
Hi Martin,

We tried with a few different setups and ROM versions and still count not recreate the problem you have reported.
The issue will be put on the back burner for moment.

Thanks,
Ken

lpcware · ‎06-15-2016

Content originally posted in LPCWare by capiman on Mon Sep 02 09:04:18 MST 2013
Hi Marc,

many thanks for the offer. But i don't want to spend more time
on this problem. It is not more a problem for me anymore.
NXP must decide what to do with this reported error.

Best regards,
Martin

lpcware · ‎06-15-2016

Content originally posted in LPCWare by MarcVonWindscooting on Mon Sep 02 08:39:13 MST 2013
Hi Martin,

I can send you a 812FD20 (SOIC20), rev '2A' (13.2 I believe), if you like to de-solder the 'very old' one to replace it by a newer.
The latest chips are different again. Even changing the boot loader enable pin from PIO0_1 to PIO0_12, if I remember correctly.

I'm sure you have the equipment for desoldering the old one without destroying.
We're living less than 200km apart, so sending by DHL will be pretty affordable ;-)

lpcware · ‎06-15-2016

Content originally posted in LPCWare by capiman on Mon Sep 02 06:43:15 MST 2013
Hello Marcus,

many thanks for your feedback!

Perhaps you are writing too slow? Have you checked with a logic analyzer, that you see that echo gets delayed more and more?
You see my case in above attached picture lpc812-start.jpg.
There is always some delay, because the LPC812 needs time to do processing.
If the delay is increasing from byte to byte, you sometime get an error, if more and more bytes
are transferred without and delay get over byte boundary (or perhaps 2 or 3 bytes).
If you reach end of command before this happens all is ok.

Can you perhaps first use a LPC812 with this old bootloader v13.1, to see if you can reproduce the problem at all?
So you can see if your test environment is suitable to retest this bug.

I think it is much easier for NXP to get a chip with old bootloader, than me to get a LPCXpresso with new bootloader...
The problem can be reproduced with (latest) lpc21isp and blocksize moved from 256 to 1024 bytes.
But perhaps I have a different PC or different components, which makes my transmission of bytes faster than your PC,
so it occurs earlier or more often. I think I saw it (almost each time) when i transferred a software to LPC812.

>>BTW: I use a LPCXpresso with LPC812 on it, bootloader version 13.1

>BTW, I don't know if it is possible for you to get the latest LPC8xx chip, bootloader v13.1 is really old.

LPC812 is not that long on the market, that it is already "really old".
I think i cannot select a version when buying LPCXpresso.

But besides all testing: Just about thinking about the protocol. The LPCxxx/LPCxxxx (whatever part you choose)
must be fast enough to receive all bytes and store them into RAM. Clocking is another topic, but i think, even
clocking at low speed the uC must be fast enough to receive and store the characters, when using highest possible baudrate.
Ken wrote above that there is no FIFO (not verified) in LPC812, so you get more interrupts (1 at each char), must react faster.
I think it is almost possible to do by math and cycle counting, if problem can occur under normal conditions or not.
If cycle shall be enough, where does this delay in LPC812 like in above picture come from?
It was recorded directly at RxD/TxD of LPC812.

The older parts had a possibility to stop transmission by software flow control (XON/XOFF).
Newer parts (like LPC812) seems to not have it anymore, so they must be fast enough or loosing characters.

lpc21isp is sending x bytes and waiting for x bytes.
If a byte is missing it waits endless (i think there is no timeout).
There is no functionality to recover from this error, so no CRC check if data is in RAM or not.
As written above i reduced packet size to 256 bytes. They delays accumulated not
so much, that the error occurred anymore, but this is of course no fix for this problem.

If you can't reproduce it, just close it. If you can, nothing can be done,
because bootloader is in ROM, no patching is possible, beside making packet size smaller again,
adding delays, take a chip with a new bootloader
or do other more or less difficult task to prevent occurrence of this bug.
Only possibility can be to write an errata for (old) bootloader how to avoid this error.

Best regards,

Martin

lpcware · ‎06-15-2016

Content originally posted in LPCWare by abj1819 on Mon Sep 02 01:44:20 MST 2013
Hello Martin:
I can not reproduce your problem at my side.( write 1024 bytes and check if echo is identical).
So maybe you could give more information about this issue:
1. Does this problem happened for every 1024-byte write? or just appear occasionally?
2. After error happened, have you checked if the content of RAM is correct?
3. Could you mind to give me your ISP sequence that I could reproduce it?

BTW, I don't know if it is possible for you to get the latest LPC8xx chip, bootloader v13.1 is really old. With new version, I am not sure that could solve your problem, but at least new ISP command get_CRC could be used for checking the result of Write/Program command.

Best regards,
Marcus

lpcware · ‎06-15-2016

Content originally posted in LPCWare by usb10185 on Fri Aug 30 15:42:40 MST 2013
Hi Martin,
Ok, got a clearer picture now, thanks!
Flashmagic does not seem top have the issue but I figure they are sending smaller chunks of data piecemeal to the device.
We'll look into it more and post a response next week.
Long weekend here!
Cheers,
Ken

lpcware · ‎06-15-2016

Content originally posted in LPCWare by capiman on Fri Aug 30 11:55:25 MST 2013
Hello Ken,
this problem was seen against the bootloader (ISP).
Best regards,
Martin

lpcware · ‎06-15-2016

Content originally posted in LPCWare by usb10185 on Fri Aug 30 10:42:22 MST 2013
Hi,

I think the issue is related to the fact that the new UART in the LPC800 family does not have a FIFO.
If the code pulling the characters into the RAM buffer does not keep up, then characters will be dropped.
Maybe check the Overrun bit in the UART status register?

Thanks,
Ken

lpcware · ‎06-15-2016

Content originally posted in LPCWare by MarcVonWindscooting on Tue Jul 30 07:06:59 MST 2013
Is this problem resolved? What revision of the chip did you use?

I ran into a similar problem. I transmitted 64 bytes only at some point of my despair. There were always characters missing in the reply, sometimes nearly half of them. The response was delayed way too much and when I reduced to 32 bytes / transmit, the reply vanished altogether. Needless to say, I found no relationship between number of sent bytes and number of received bytes, not even on the same shared contents.

I finally found out, that LPC800 uses more RAM from the lower addresses (0x270) than some earlier parts. As my program is using all of the RAM not used by the ISP handler and I configured it too low (0x240) I ended up in overwriting the ISP handlers RAM area - OMG! :Sp

lpcware · ‎06-15-2016

Content originally posted in LPCWare by capiman on Fri Jun 28 06:24:27 MST 2013

Arg, now they were displayed by forum. Never mind, here are two screenshots.

lpc812-start.jpg: This shows the start of the binary data, which is sent after 'W' command. Time (see red and green boxes) is around 100 us from the time

where the PC (or better USB -> serial converter) delivers the binary data, to the time where LPC812 delivers the data.

lpc812-lost1.jpg: This shows the error case. Time to answer (violet box) is now 326 us.

Sent bytes are 0xC1, 0x48, 0xC1, 0x4A.

Echoed bytes are 0xC1, 0x48, 0x4A (0xC1 is missing). All the following bytes are correct again.

I saw 4 such cases in one 1024 byte transmission.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by capiman on Fri Jun 28 06:07:04 MST 2013

Unfortunately the marker get lost which point to the position of the errors.

Here the data which was sent to LPC812:

'#(FB)?J>I(80)#(CB)X@!(19)C(80)#(D1)P(00) (07)!(01)"(01)(F0)n(FF)(00) (10)!(01)"(01)(F0)i(FF)(00) (11)!(01)"(01)(F0)d(FF)(00) (07)!(01)"(01)(F0);(FF)(00) (10)!(00)"(01)(F0)6(FF)(00) (11)!(01)"(01)(F0)1(FF)(96)#(9B)(01)(00) (19)(1C)(00)(F0)W(FD)*K(18)(1C)(00)(F0)o(FD))K(18)(1C)(00)(F0)k(FD)$K[h(18)(1C)(00)(F0)(80)(FD)%K(18)(1C)(00)(F0)b(FD)$K(18)(1C)(00)(F0)^(FD)(1D)K(9B)h(18)(1C)(00)(F0)s(FD)(1F)K(18)(1C)(00)(F0)U(FD)(1F)K(18)(1C)(00)(F0)Q(FD)(17)K(DB)h(18)(1C)(00)(F0)f(FD)(18)K(18)(1C)(00)(F0)H(FD)(19)K(18)(1C)(00)(F0)D(FD)(10)K(1B)i(18)(1C)(00)(F0)Y(FD)(12)K(18)(1C)(00)(F0);(FD)(14)K(18)(1C)(00)(F0)(FD)(FA)(C0)F(12)K(9A)h(08)#(13)@(FA)(D0)(11)K(04)"(1A)`(0F)K(02)"(1A)`(0F) (FF)(F7)(B6)(FE)(0F) (FF)(F7)(9B)(FE)(BD)F(02)(B0)(80)(BD)(00)(00)(02)@(00)(80)(04)@(B4)&(00)(00)(C0)&(00)(00)(90)&(00)(00)(CC)&(00)(00)(D8)&(00)(00)(E4)&(00)(00)(F0)&(00)(00)(00)@(06)@(00)(80)(00)@(90)(B5)(8B)(B0)(00)(AF)(01)(F0)(8B)(FA)(E4)J(E3)I(80)#(CB)X@!(19)C(80)#(D1)P(00) (07)!(01)"(01)(F0)(D6)(FE)(00) (10)!(01)"(01)(F0)(D1)(FE)(00) (11)!(01)"(01)(F0)(CC)(FE)(00) (07)!(01)"(01)(F0)(A3)(FE)(00) (10)!(01)"(01)(F0)(9E)(FE)(00) (11)!(00)"(01)(F0)(99)(FE)(96)#(9B)(01)(00) (19)(1C)(00)(F0)(BF)(FC)(00) (06)!(01)"(01)(F0)(B2)(FE)(00) (06)!(01)"(01)(F0)(89)(FE)(C9)J(C8)I(80)#(CB)X(80)!(09)(01)(19)C(80)#(D1)P(C4)K(C4)JRh(01)!(8A)CZ`(C1)K(C1)JRh(01)!(0A)CZ`(BF)K(DB)h{b(BE)K(1B)i;b{j(1B)(02)(1B)(0A){b{j(E0)"(12)(05)(13)C{b;j(FF)"(93)C;b;j(0C)"(13)C;b:j(B4)K(13)@;b;j(D0)"(12)(01)(13)C;b:j(B1)K(13)@;b;j(FF)"(12)(04)(13)C;b(AB)Kzj(DA)`(A9)K:j(1A)a(AB)K$"(1A)`(A9)K(80)"(12)(02)Zb(A7)K(F1)"(12)(05)(1A)b(A5)K(A5)J(12)h(01)!(0A)C(1A)`(A3)K(18)(1C)(00)(F0)x(FC)(A2)K(18)(1C)(00)(F0)t(FC)(9A)K(1B)k(18)(1C)(00)(F0)(89)(FC)(9F)K(18)(1C)(00)(F0)k(FC)(9E)K(18)(1C)(00)(F0)g(FC)(9D)K(1B)x(18)(1C)(00)(F0)T(FC)(9A)K[x(18)(1C)(00)(F0)O(FC)(98)K(9B)x(18)(1C)(00)(F0)J(FC)(95)K(DB)x(18)(1C)(00)(F0)E(FC)(93)K(1B)y(18)(1C)(00)(F0)@(FC)(8E)K(18)(1C)(00)(F0)J(FC)(8E)KH"(1A)p(8D)Ka"Zp(8B)Kl"(9A)p(8A)Kl"(DA)p(88)Ko"(1A)q(00)(E0)(C0)F(00)(F0)(E9)(F9)(03)(1C)(00)+(F9)(D0)<(1C)(1F)4(00)(F0)(EC)(F9)(03)(1C)#p;(1C)(1F)3(1B)xw+(00)(D0)(19)(E1)~K(18)(1C)(00)(F0)$(FC)zK(18)(1C)(00)(F0) (FC)yK(1B)x(18)(1C)(00)(F0)(0D)(FC)wK[x(18)(1C)(00)(F0)(08)(FC)tK(9B)x(18)(1C)(00)(F0)(03)(FC)rK(DB)x(18)(1C)(00)(F0)(FE)(FB)oK(1B)y(18)(1C)(00)(F0)(F9)(FB)kK(18)(1C)(00)(F0)(03)(FC)bJaI(80)#(C9)XkK(19)@(80)#(D1)PjKiJ(12)h(80)!(09)(01)(0A)C(1A)`fKfJ(12)h(80)!I(00)(0A)C(1A)`dK(18)(1C)(00)(F0)(AF)(F9)(C0)FbK(9A)h(08)#(13)@(FA)(D0)^K`JZ`\K`J(9A)`[K_J(DA)`YK_J(1A)aLJKI(80)#(CB)X(80)!(89)(00)(19)C(80)#(D1)PGKGJQhQJ(0A)@Z`DKDJRh(80)!(89)(00)(0A)CZ`MKLJRi(0C)!(0A)CZa(0F) (FF)(F7)(18)(FD)OK(04)"(1A)`NKNJ(DA)`LK(01)"(1A)`8J7I(8E)#(9B)(00)(C9)X(8D)#(9B)(00)(D1)P4J(85)#(9B)(00)(80)!(09)(02)(D1)PFK'

Here the data which was received by PC:

'#(FB)?J>I(80)#(CB)X@!(19)C(80)#(D1)P(00) (07)!(01)"(01)(F0)n(FF)(00) (10)!(01)"(01)(F0)i(FF)(00) (11)!(01)"(01)(F0)d(FF)(00) (07)!(01)"(01)(F0);(FF)(00) (10)!(00)"(01)(F0)6(FF)(00) (11)!(01)"(01)(F0)1(FF)(96)#(9B)(01)(00) (19)(1C)(00)(F0)W(FD)*K(18)(1C)(00)(F0)o(FD))K(18)(1C)(00)(F0)k(FD)$K[h(18)(1C)(00)(F0)(80)(FD)%K(18)(1C)(00)(F0)b(FD)$K(18)(1C)(00)(F0)^(FD)(1D)K(9B)h(18)(1C)(00)(F0)s(FD)(1F)K(18)(1C)(00)(F0)U(FD)(1F)K(18)(1C)(00)(F0)Q(FD)(17)K(DB)h(18)(1C)(00)(F0)f(FD)(18)K(18)(1C)(00)(F0)H(FD)(19)K(18)(1C)(00)(F0)D(FD)(10)K(1B)i(18)(1C)(00)(F0)Y(FD)(12)K(18)(1C)(00)(F0);(FD)(14)K(18)(1C)(00)(F0)(FD)(FA)(C0)F(12)K(9A)h(08)#(13)@(FA)(D0)(11)K(04)"(1A)`(0F)K(02)"(1A)`(0F) (FF)(F7)(B6)(FE)(0F) (FF)(F7)(9B)(FE)(BD)F(02)(B0)(80)(BD)(00)(00)(02)@(00)(80)(04)@(B4)&(00)(00)(C0)&(00)(00)(90)&(00)(00)(CC)&(00)(00)(D8)&(00)(00)(E4)&(00)(00)(F0)&(00)(00)(00)@(06)@(00)(80)(00)@(90)(B5)(8B)(B0)(00)(AF)(01)(F0)(8B)(FA)(E4)J(E3)I(80)#(CB)X@!(19)C(80)#(D1)P(00) (07)!(01)"(01)(F0)(D6)(FE)(00) (10)!(01)"(01)(F0)(D1)(FE)(00) (11)!(01)"(01)(F0)(CC)(FE)(00) (07)!(01)"(01)(F0)(A3)(FE)(00) (10)!(01)"(01)(F0)(9E)(FE)(00) (11)!(00)"(01)(F0)(99)(FE)(96)#(9B)(01)(00) (19)(1C)(00)(F0)(BF)(FC)(00) (06)!(01)"(01)(F0)(B2)(FE)(00) (06)!(01)"(01)(F0)(89)(FE)(C9)J(C8)I(80)#(CB)X(80)!(09)(01)(19)C(80)#(D1)P(C4)K(C4)JRh(01)!(8A)CZ`(C1)K JRh(01)!(0A)CZ`(BF)K(DB)h{b(BE)K(1B)i;b{j(1B)(02)(1B)(0A){b{j(E0)"(12)(05)(13)C{b;j(FF)"(93)C;b;j(0C)"(13)C;b:j(B4)K(13)@;b;j(D0)"(12)(01)(13)C;b:j(B1)K(13)@;b;j(FF)"(12)(04)(13)C;b(AB)Kzj(DA)`(A9)K:j(1A)a(AB)K$"(1A)`(A9)K(80)"(12)(02)Zb(A7)K(F1)"(12)(05)(1A)b(A5)K(A5)J(12)h(01)!(0A)C(1A)`(A3)K(18)(1C)(00)(F0)x(FC)(A2)K(18)(1C)(00)(F0)t(FC)(9A)K(1B)k(18)(1C)(00)(F0)(89)(FC)(9F)K(18)(1C)(00)(F0)k (9E)K(18)(1C)(00)(F0)g(FC)(9D)K(1B)x(18)(1C)(00)(F0)T(FC)(9A)K[x(18)(1C)(00)(F0)O(FC)(98)K(9B)x(18)(1C)(00)(F0)J(FC)(95)K(DB)x(18)(1C)(00)(F0)E(FC)(93)K(1B)y(18)(1C)(00)(F0)@(FC)(8E)K(18)(1C)(00)(F0)J(FC)(8E)KH"(1A)p(8D)Ka"Zp(8B)Kl"(9A)p(8A)Kl"(DA)p(88)Ko"(1A)q(00)(E0)(C0)F(00)(F0)(E9)(F9)(03)(1C)(00)+(F9)(D0)<(1C)(1F)4(00)(F0)(EC)(F9)(03)(1C)#p;(1C)(1F)3(1B)xw+(00)(D0)(19)(E1)~K(18)(1C)(00)(F0)$(FC)zK(18)(1C)(00)(F0) (FC)yK(1B)x(18)(1C)(00)(F0)(0D)(FC)wK[x(18)(1C)(00)(F0)(08)(FC)t (9B)x(18)(1C)(00)(F0)(03)(FC)rK(DB)x(18)(1C)(00)(F0)(FE)(FB)oK(1B)y(18)(1C)(00)(F0)(F9)(FB)kK(18)(1C)(00)(F0)(03)(FC)bJaI(80)#(C9)XkK(19)@(80)#(D1)PjKiJ(12)h(80)!(09)(01)(0A)C(1A)`fKfJ(12)h(80)!I(00)(0A)C(1A)`dK(18)(1C)(00)(F0)(AF)(F9)(C0)FbK(9A)h(08)#(13)@(FA)(D0)^K`JZ`\K`J(9A)`[K_J(DA)`YK_J(1A)aLJKI(80)#(CB)X(80)!(89)(00)(19)C(80)#(D1)PGKGJQhQJ(0A)@Z`DKDJRh(80)!(89)(00)(0A)CZ`MK JRi(0C)!(0A)CZa(0F) (FF)(F7)(18)(FD)OK(04)"(1A)`NKNJ(DA)`LK(01)"(1A)`8J7I(8E)#(9B)(00)(C9)X(8D)#(9B)(00)(D1)P4J(85)#(9B)(00)(80)!(09)(02)(D1)PFK'

With the logic analyzer it was confirmed that not the USB <-> Serial converter is loosing characters, they are already lost before the converter gets data from the LPC812.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by capiman on Fri Jun 28 06:04:31 MST 2013

Here a logic analyzer trace recorded with old digiview DV1-100 (from tech tools)