Notes on entering ISP mode after a program has started

IAP notes

The explanation in UM10360 "32.8 IAP commands"is quite clear:

• There is a procedure for calling IAP from C code
• You don't need to worry about putting the pointers into R0 and R1 as if you follow the given code it just happens that way
• The odd scheme is used because the way that two pointers are passed into a procedure is meant to be universal. Passing conventions for non-pointers or more than two parameters vary from compiler to compiler.
• Flash read and write operations use the TOP 32 bytes of RAM. This is clearly stated.
• I understand that MBED may start the stack from the top of RAM by default but I have not checked
• I believe it might be possible to open up a gap by declaring some local storage in "main" but this is a guess not backed by data
• I'm going to assume that IAP may make some use of the stack
• Assuming the stack is safe it should be possible to use local memory for the command block, just because it is on the stack it is not going to move anywhere
• If we are not using pre-built commands we can use the same array for command AND response
• Alternatively we could declare the command block as initialised with its values
• If we are re-invoking ISP then there is no return so no need for a return block so just pass the command block twice
• It clearly states that flash memory is inaccessable during a flash erase or write
• I haven't found the specific instructions about interrupts having to be disabled yet. I can see why they might need disabling especially for a flash write when the memory the handler resides in is unavailable, but I canot see it actually stated
• The specific advice that the interrupt handler must either reside in RAM or be disabled appears later in the text under "32.10 Flash signature generation" The signature generator appears to be a hardware block and not an IAP function
• I cannot find anything saying the IAP entry process is not interrupt safe. If true then this might have come from an appnote.

ISP entry notes

32.8.9 Re-invoke ISP Command code: 57(decimal)

• PCLK = CLK / 4 PCLK is Peripheral clock?
• The "another option" is to disable the PLL and select IRC
• But this means the ISR uses the PLL
• So does this mean it tests the PLL configuration at entry? I'm getting the impression that what NXP are saying is that if the clock is in its power-on-default state then the bootloader will reconfigure it as required, but that if it is already configured then it will use its current state?
• The reason for wanting to use Power-ON defaults is that it ensures that the standard ISP settings will work, the programmer does not need to know the external clock frequency.
• The clock frequency thing may be a misunderstanding on my part. It is possible that the benefits of running with an external crystal during programmimg may outweigh the disadvantage of the frequency needing to be known, but if so then:
  • Why isn't the clock frequency supplied as part of the IAP call
  • Why isn't it more clearly documented exactly which frequency to supply (crystal or post-PLL)
  • Why doesn't the ISP programmer upload a short program to RAM that configures the clock then re-enters programming mode, allowing a blank device to be programmed at full speed
• Depending on the programming tool used the device may leave reset with IRQ disabled if the IAP call was used instead of peripheral pin. This may be because some programmers simply "jump" to the reset vector to start the main program instead of triggering a reset. Normally if the device was reset into programming mode this would make no difference
• The LPC MBED library assumes IRQ will be enabled.

Sam Grove's ISP example

https://developer.mbed.org/users/sgrove/code/Re-InvokeISP/ The example is given as a program not a library but it should not be hard to adapt, probably as little as renaming "main".

Clock configuration Forum Thread

https://developer.mbed.org/forum/mbed/topic/229/?page=2

Compiling LPC21ISP using Visual Studio Community 2017

It just works. I used the "x64 Native Tools Command Prompt for VS 2017" shortcut in the "Visual Studio 2017" start menu folder. I think if I was building the "exe" to distribute I would use x86 though.

Flash Magic

I can not recommend Flash Magic for programming MBED binaries. It still requires code to be supplied in HEX form not binary. It now appears to be bundled with a hex file tool called srec (presumably originally intended to deal with Motorola "S-records"?) which can convert from the mbed bin to an Intel hex format suitable for FM. As far as I am aware the LPC1768 MBED binary has an offset of zero.

Example command: srec_cat.exe GP9002af_gray_LPC1768.bin -bin -o GP9002af_gray_LPC1768.hex -intel

The process just seems much more slow and laborious than with LPC21ISP, added to which the first time I tried flash magic I managed to get a dialog box hidden under a window and the applicaton deadlocked, and needed to be closed from task manager.

The VS download was 6GB+, rather excessive for one command-line compilation so I intend to try using cygwin/GCC in future

Automatically re-entering programming mode

• LPC21ISP supports the use of serial port handshake lines to enter ISP mode
• The FTDI USB-serial cable only provides one HS line
• An alternative software method is being tested, in the alternative strategy an ISR looks for the "sync" character on the serial port pin. To avoid conflict with serial the pin is configured first and a baud-independant recognition routine is used