re-invoke ISP for USB0 and DFU

[lpcware]

Content originally posted in LPCWare by ASCOTJan-H on Tue Jul 15 01:13:17 MST 2014
Hi

We would like to use the DFU tool, to updated our FW and flash the LPC1857 over USB0. To do so we are trying to re-invoke the ISP mode, from application code. If we call our re-invok ISP function, the LPC is detected by the DFU tool as "HIGH SPEED USB" but fails during "Waiting up to 6s for programming algorithm detection after DFU download" with the error message "Board programming algorithm failed to start". If we invoking the ISP with PIN P2_7 we can program the LPC without any problem.

We using:
- a LPC1857 on a custom board with no real access to P2_7
- Keil MCB1800 development board
- LPCXpresso v6.1.2 [Build 177] [2013-11-28]
- dfusec v1.11

Code:
void invokingISPmode(){

  volatile unsigned int i = 0;
  __disable_irq();
  for (i = 0; i < 10000000; i++)
      ;

//Reset register
  LPC_RGU->RESET_CTRL0 = 0x387F1200;
  LPC_RGU->RESET_CTRL1 = 0x17FFF7FF;

  for (i = 0; i < 10000000; i++)
      ;

//Invoke ISP
  unsigned int command[5];
  unsigned int result[4];
  command[0] = 57;
  iap_entry(command,result);

  while(1){
  }
}

We also did try this example -> http://www.lpcware.com/content/forum/lpc1857-jump-usbdfu-bootloader-application
but during "((void(*)(int))0x1040214D)(LPC_OTP_BASE); // Clocks_Init"  The Application runs into the HardFault_Handler.

We do suspect, that some configuration register is not set correctly and causes this behavior. Is there any documentation we can use to see what register need to be set to re-invoke ISP mode from application software?

[lpcware]

Content originally posted in LPCWare by cvgkrishna on Wed Jan 06 07:58:06 MST 2016
We are using this example with lpc18s37 lpcxpresso board. IDE we are using is LPCXpresso latest version 8 bootloader version is 12.2(0C02)
we are facing below issues
[1] We tried "re-invoke ISP for USB0" example,we are able to detect the board but it is failing  after the 4s delay using DFU utility
[2] We tried using this example lpc18xx_43xx-start-dfu.zip  but it is going into some unknown state. while debugging it is going to hard fault
we already came to know from different post that we should not be using it in debug mode.
[3]We tried this example in Release and Debug both the modes but of no luck
[4] We are assuming this example already takes care of setting core to 96 MHz Mode.Please confirm.

If possible Can you upload your working code for lpcxpresso tested on 18s37

Thanks
Gopal

[lpcware]

Content originally posted in LPCWare by ASCOTJan-H on Mon Aug 04 06:20:37 MST 2014

---

Quote: bavarian

Did you try to wind-back a little bit your application setup. With "wind-back" I mean some sort of "getting back into bootloader state".
The bootloader for example runs on 96MHz, if your application runs on 180MHz then this could create a problem.

---

With didn't try with 96MHz. Could be the problem.

[lpcware]

Content originally posted in LPCWare by bavarian on Mon Aug 04 06:01:00 MST 2014
With regards to this example: http://www.lpcware.com/content/forum/lpc1857-jump-usbdfu-bootloader-application

On my boards (Keil + Hitex) this example works fine. It is intended to be used for systems where the bootmode is not set to USB0. At the point in time the bootloader loads the value of the bootmode pins the FPB unit (flash patch and breakpoint unit) is used to fake the value and tells the bootloader that the bootmode is set to USB0.

If the bootmode on your board is already set to USB0 then the example should also work. No matter what has been latched from the pins P2_7 and the 4 bootmode pins after reset, the patch replaces the result in R0 by 0x15. The "1" simulates the ISP pin (inverted read) and the "5" the USB0 bootmode.

Did you try to wind-back your application setup a little bit? With "wind-back" I mean some sort of "getting back into bootloader state".
The bootloader for example runs on 96MHz, if your application runs on 180MHz then this could create a problem.

There is no official way to re-invoke ISP in USB0 mode, so this example really implements a patch of the existing bootloader.
If you debug into this example, please consider that also the debugger uses the FPB unit and will erase your settings for the patch code.
So if you come that far in your debug process (at the patch address) you will notice that the result of the bootstrap query doesn't get patched to 0x15, simply because the respective FPU settings do not longer exist.

Regards,
NXP Support Team

[lpcware]

Content originally posted in LPCWare by ASCOTJan-H on Sun Aug 03 23:22:46 MST 2014
Sadly no. We did contact the nxp support, but there take a lot of time to answer. So we did write our own flash function, to keep up with our schedule.

We used the USB bulk endpoint and IAP to write the new flash image into bank B and copy bank B to A with a function located inside of the ram and restart the LPC. Works fine for us.

[lpcware]

Content originally posted in LPCWare by MX21 on Wed Jul 30 11:35:26 MST 2014
Did you figure this out?  I need to do the same thing.

Thanks