lpcware

ISP protocol again changed?

Discussion created by lpcware Employee on Jun 15, 2016
Latest reply on Jun 15, 2016 by lpcware
Content originally posted in LPCWare by capiman on Wed Dec 05 14:38:18 MST 2012
Hello,

just started to adapt lpc21isp for new LPC812 (got it today on a LPCxpresso).

It looks like ISP protocol has changed compared to previous LPCxxxx.

But description in user manual seems to be not sufficient and wrong. Here are only some points:

1) According to User Manual UM10601 (Rev. 1 — 9 November 2012)
"21.5.1 UART Communication protocol
All UART ISP commands should be sent as single ASCII strings. Strings should be
terminated with Carriage Return (CR) and/or Line Feed (LF) control characters. Extra
<CR> and <LF> characters are ignored. All ISP responses are sent as <CR><LF>
terminated ASCII strings. Data is sent and received in plain binary format."

1A) Is it correct, that strings can be terminated with CR "and/or" (!!!) LF?
E.g. when sending 'U 23130(0A)', i get no answer (but only with LPC8xx, used the same string with other LPCxxxx and there it is working...)
But when sending 'U 23130(0D)(0A)', i get an answer -> 'U 23130(0D)(0A)0(0D)(0A)'

Same for 'K(0A)' compared to 'K(0D)(0A)', 'J(0A)' compared to 'J(0D)(0A)' and so on.
Bootloader version of my LPC812 seems to be 13.1

What is the recommend way to send these command strings, also for other LPCxxxx? Always send (0D)(0A)? Always send (0A)?
Or must it even be different for different LPCxxxx, or even different versions of same LPCxxxx?

1B) Is it correct that we are now sending plain binary data? No more UUENCODE? No more checksum?

2) Crystal frequency seems now to be hard coded by bootloader to 12 MHz. What happens when i use a faster crystal, e.g. 30 MHz?
Does programming to flash still work (regardless of allowed temperature, crystal speed...)?

Best regards,

Martin

Outcomes