LPC9xx baud rate tolerance

[Werner]

Hallo Andy,

i found a problem in flashmagic (Version V4.33.1397):
During programming flashmagic sends records of 64 bytes data plus some more for address, checksum etc. All bytes are sent with maximum speed without any gaps between them (just 1 stop bit).
The ISP bootloader resides in the top region of the flash and therfore cannot use RX/TX interrupts in conjunction with RAM buffers. Since the chip has to echo every received byte the bootloader can receive bytes only as fast as its transmissions are. If the chip's baud rate is slightly slower than flashmagic's baud rate and there are many bytes to receive (and to send back), at some time flashmagic overflows the bootloader and one byte is lost. Them programming stucks and a transmit/receive error occours. This also occous with the ICP-bridge at 19200 baud.

The tolerance of the LPC9xx RC-oscillator has become worse. In the beginning almost every LPC932 had +/-1%, now there are many LPCs with +/-2.5%


So now my question:
Is it possible to insert a time gap of 1 byte every 16 or 32 bytes? Then the chip would be able to catch up timing.

I've got a second question:
I modified the bootloader to autobaud up to 115200 baud. Who is the right person at NXP to make a suggestion?

Kind regards
Werner

[Andy Ayre]

Werner,

Under what conditions do you see the 2.5% deviation? 1% is only expected at room temperature for example. So what temperature and voltage are your devices running at?

Also if VDD is not properly decoupled it can affect the internal RC oscillator.

Andy

[Werner]

Hi Andy,

the first LPC935 i grabbed had -1.5% with clean 3.2V at room temperature. This may still comply with the specification (+/-2.5% over full temp, nothing else).
But this deviation of -1.5% is already too slow for the ICP bridge to perform programming (every other command works).

The problem is not the baud rate deviation itself. Serial communication normally works with a baud rate mismatch of 3% and this is also true for the LPCs. The problem is the missing buffer memory and the long data records that have to be echoed in time. A full-length (64 bytes) program record contains 137 bytes and these are used in FlashMagic. But even with -1% after 100 bytes the "one-byte buffer SBUF" has reached the end.
Positive deviations are no problem at all because then the echo is sent faster than the next byte comes in.

I think there are two possible solutions:

1. In FlashMagic:
Time gaps in transmission after 32 bytes.

2. In the ICP-bridge:
Enabling UART double buffering mode (halfes the deviation problem),
Using an accurate autobaud measurement (reduces the deviation itself).

I sucsessfully tried the second solution. Unfortunately the ICP-bridge code is available as a hex-file only. I had to disassemble the ICP-bridge code to insert my autobaud/double buffer routine. So it's a job for NXP to do.


Basically the ISP-bootloader suffers from the same problem. But due to a rounding bug in the bootloader autobaud function the detected baud rate tends to be a little faster. (In fact this is the reason why communication only works with baudrates up to 7200 baud.) So nobody has experienced the deviation problem with the ISP-bootloader yet. But with high speed communication the deviation problem shows up again.

so, long
Werner

[Andy Ayre]

Version 4.34 inserts a 1ms delay halfway through long (more than 32 bytes of data) hex records.

Andy