Does USB Bootloading in CRP1 always erase all Flash?

[mattferrari]

I'm hoping someone can answer this question...

When USB Bootloading via the built-in ROM Bootloader on the LPC11U68 with CRP set to CRP1, if the first 8 entries in the vector table qualify the download (i.e. they add  up to 0), will the entire flash then be erased prior to programming the download image into flash, irrespective of the size of the downloaded image?

Thanks.

[mattferrari]

Hi Ping - 

Can you please advise regarding the expected availability of the LPCOpen code example for the LPC11U68 USB Secondary Bootloader we've been discussing?  Our product release is on hold pending resolution of this issue, we really need this information - please advise.

Thank you Ping, I look forward to your reply.

Matt

[jeremyzhou]

Hi Matt,

Please try the demo with your board and contact with me freely if you have any questions.
Have a great day,
Ping

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[mattferrari]

Thank you Jeremy.

Matt

[jeremyzhou]

Hi Matt,

The lpc11u6x_usbd_rom_msc base on the USB ROM API and I can work well.

                           Fig 1

In my plan, I'd like to receive the data in translate_GetWrBuf() which is called when host sends SCSI_WRITE10/SCSI_WRITE12 command, so I adapted the function which illustrated below.

However I hadn't found anything changes of the values of the array Copy_data when I copied some bin files to the LPCUSBlib driver.

So I need to try other approaches to work it out.

/* USB device mass storage class get write buffer callback routine */
static void translate_GetWrBuf(uint32_t offset, uint8_t * *buff_adr, uint32_t length, uint32_t hi_offset)
{
     memcpy((void *)&Copy_data, (void *)(*buff_adr),length);
     *buff_adr =  &g_memDiskArea[(((uint64_t) offset) | (((uint64_t) hi_offset) << 32))];

}‍‍‍‍‍‍‍

Thanks for your understanding.

Best regards,

Jeremy

[mattferrari]

Hi Ping - 

There is no need to download the sample bundle and port the MSC project over to LPCOpen for the LPC11U68.  There already is an LPCOpen MSC project for the LPC11U68 - I attached it to my last email to you.

I am able to run that LPC11U68 MSC project and see the enumeration occur in Windows Explorer.

The old RDB USB Secondary Bootloader project was for the 1768.  It has a different architecture than the 11U68, a different memory map, different linker script and since it wasn't written for LPCOpen, all the function calls are different.  Not being knowledgeable about how to code for USB, I am unable to port the 1768 Bootloader project over to the 11U68.

But given that we now have an LPCOpen MSC project for the 11U68, I would think that one of your AEs would be able to do the porting because they would easily be able to see where the modifications would be needed, whereas I am not able to do that.

You had indicated in an earlier email that you would request one of your AEs to provide an example LPCOpen project for a USB Secondary Bootloader for the LPC11U68 - I am hoping you are still intending to provide that.  Given that the LPCOpen MSC project for the LPC11U68 is already written, I would think that for one of your AEs, this providing this example bootloader project would be a fairly straightforward task. 

I am hopeful that since there is no way to securely use the ROM Bootloader on the LPC11U68, NXP will be willing to provide this example project for the users of this chip as a work around for this issue.

Thanks Ping,

Matt

[jeremyzhou]

Hi Matt,

I've almost completed the porting, and I'll upload the demo later.

Thanks for your patient.

Best regards,

Jeremy

[mattferrari]

Thank you Jeremy,

Matt

Sent from my Verizon, Samsung Galaxy smartphone

[jeremyzhou]

Hi Matt Ferrari,

Thanks for your reply.

I've also found none of USB Secondary Bootloader demos for the LPC11U68 yet.

However we can create the USB Secondary Bootloader demo for LPC11U68 through the following steps.

1. Download the sample code bundle for LPC11U1x/2x/3x periherals using LPCXpresso

    2. The sample code bundle has the USB_ROM_MSC demo, then port the the demo to the LPCOpen: lpcopen_2_06_lpcxpresso_nxp_lpcxpresso_11u68, you can name the demo such as usb_bootloader

    3. As you mentioned in the above, the Sample code bundle for RDB1768 using LPCXpresso and Red Suite | www.LPCware.com has the USB Secondary Bootloader project. Then you can port the project to the new demo in the LPCOpen.

I'm working now, and you can also have a try.
Have a great day,
Ping

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[mattferrari]

Hi Ping - 

The current version of the LPCXpresso IDE has example projects for many USB applications like HID, but does not include one for MSC, which is of course the heart of a USB Secondary Bootloader.  I thought that was very unfortunate as perhaps it could have provided useful information for people interested in this topic.  

After much searching, I found that NXP HAS designed such an MSC example project for the LPC11U6x, it just doesn't appear in the IDE and never showed up anywhere as I was doing my exhaustive internet search on this topic.

I have attached it to this post so that others who may be interested in an LPCXpresso example for a USB MSC application specifically for the LPC11U68 might benefit from this resource.

With the knowledge now that the MSC functionality has ALREADY been developed for the LPC11U6x, it should be a trivial exercise for one of your AEs to leverage the two existing projects: "usbd_rom_libusb" and "usbd_rom_msc_ram" to make a simple USB Secondary Bootloader example project to build in the LPCXpresso IDE.

Ping, can you advise regarding when this example USB Secondary Bootloader for the LPC11U6x might be available to us?

Thanks again for your support Ping,

Matt

[mattferrari]

Hi Ping -

I just thought I'd mention regarding USB on LPC11U68, there is an Errata Sheet dated 28 JULY 2014, which identifies two bugs in the USB ROM routines:

USB_ROM.1 The USB ROM driver routine hwUSB_ResetEP() accidentally corrupts the subsequent word of memory while clearing the STALL bit of the selected endpoint.

USB_ROM.2 The USBD ROM stack doesn't split EP0 transfer into multiple packets

I am attaching the Errata to this email for your reference.  Can you please make sure that the AEs include the necessary code to address these bugs as needed in their USB Secondary Bootloader application for the LPC11U68?  The workarounds are included in the Errata.

Thanks Ping,

Matt

[mattferrari]

Hi Ping -

Yes, on the old site "LPCware.com" there is a download for the file: code.bundle.rdb1768.cmsis_.zip

Here's the link: Sample code bundle for RDB1768 using LPCXpresso and Red Suite | www.LPCware.com 

There are lots of projects in there and one of them is the USB Secondary Bootloader project.

I have attached a ZIP file which includes just the projects needed to build the bootloader. 

We built this project and ran it on an LPC1768 LPCXpresso board and it works just fine. 

Now all we need is to have it ported over to the LPC11U68.

There are also other NXP App Notes for USB Secondary Bootloaders: AN10759, AN10711, AN10866, AN10764

I hope this helps, thanks again Ping.

Matt

[mattferrari]

Hi Ping -

Thank you SO much for requesting the example LPCXpresso project for a USB Secondary Bootloader for the LPC11U68!  I think there is much interest in having this solution.  So far 187 views for this topic!

We have learned the following things during this discussion:

1) CRP1 does not preserve Sector-0 when bootloading over USB

2) Regardless of CRP0, CRP1 or CRP2, entire flash code image is lost simply by deleting "firmware.bin"

3) CRP3 is the ONLY way to secure the application code against accidental or malicious deletion via USB bootloader

4) But when using CRP3, the USB bootloader is no longer available for use

5) Between #2, #3 & #4 above, there is no way to realize a secure ROM-based bootloader on the LPC11U68

The consequences of the above have dire implications for users of this chip, who quite likely selected this chip because of the built-in USB Bootloader, I know I did!  The realization that there is no secure way to use it, however is a harsh and heat-breaking realization.  HOWEVER there is one (and only one) solution, and you have requested that it be provided to LPC11U68 users.  THANK YOU PING!

I have reviewed the USB Secondary Bootloader example LPCXpresso project which is already available for the LPC1768.  The project is not very big and I expect that for one of your AEs, it will be a simple exercise to port the LPC1768 example over to the LPC11U68 and make it available for us all.  It really is vital for us to have this - there is no other way to securely bootload this chip.

Because we are about to go into production with this design, can you give me an estimate regarding when this new example code might become available?  The rest of our design has been completed and is in Beta with the intention to go to general availability as soon as this bootloader issue is resolved.   This is the last piece of the puzzle and we are very excited to know that it will soon be resolved.

Thank you again Ping!  You are making a big difference for a lot of developers here!

Matt

[jeremyzhou]

Hi Matt Ferrari,

Thanks for your reply.

I was wondering if you can upload the demo which can be used with LPC1768.

Did you find it in the Welcome to LPCware.com! | www.LPCware.com 

I'm looking forward to your reply.
Have a great day,
Ping

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[mattferrari]

And one further question...  AN11732 says it's an "LPC11U3x/2x USB Secondary Bootloader".  Will this work as-is for the LPC11U68?

[jeremyzhou]

Hi Matt Ferrari,

The AN11732's approach seem be a little complicated versus the "drag-n-drop" update method, and I will contact with the AE team to apply for the kind of demo to implement  "drag-n-drop" update solution for LPC11U68.

Have a great day,
Ping

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[mattferrari]

Hi Ping - thank you for getting resolution on this issue.  It is very helpful to finally understand exactly what's happening.  But unfortunately, the truth of this matter has some very unfortunate consequences.

This confirms that all of the App Notes which talk about using CRP1 to protect Sector-0 from being written failed to mention that this wouldn't work when using the USB Bootloader, because the whole flash, including Sector-0, gets deleted when "firmware.bin" is deleted.  This has serious consequences for anyone (such as myself) who has developed a product using the USB interface with the expectation that secure field updates could be performed using the "drag-n-drop" method in Windows Explorer.  It appears that this will not be possible without using CRP3 and a Secure USB Secondary Bootloader.

NXP has provided code examples in the form of LPCXpresso projects for several other NXP processors which implement a USB Secondary Bootloader - I am still hoping for such an LPCXpresso project example for the LPC11U68 so I can customize it, integrate it into my application and still realize the "drag-n-drop" method for updating code in the field.  If you could provide such an LPCXpresso project, that would be very useful.

The alternative solution you've provided in App Note AN11732 uses a "tool" to build a composite ".bin" from the target application and an NXP provided "bin" version of a bootloader.  I need to study this more, but two things come to mind immediately:

1) AN11732 says that once programmed with this composite image, the chip is placed in CRP2 mode.  This still means that if the end product were able to be put into the native (ROM-based) Bootloader mode, that the Flash in the chip is still vulnerable to being erased by simply deleting the "firmware.bin" file using Windows Explorer, correct?

2) In that case, the end product solution would need to NOT allow the customer access to putting the chip in the native Bootloader mode, and rely solely on this new integrated composite image update method.  Which raises the next big question...

3) How feasible is this new method for end user customers (the average consumer) to use to update the firmware in the product?  Previously, a simple "drag-n-drop" solution was the method. Easy and familiar for customers to do.  It appears that this new method would require the customer to run a Script from a folder which also contains the composite binary in order to perform updates.  For Windows 7, this means that the end user now has to install a driver.  This is something beyond the ability of the average consumer to do without requiring technical support.

I am still interested in being able to use CRP3 and a Source Code USB Secondary Bootloader solution so I can still have the simple "drag-n-drop" update method.  Can you supply an example LPCXpresso project for such a solution for the LPC11U68, as is available for several of your other LPC processors?

And one further clarification...  I am assuming that if the part IS put into CRP3, then deleting "firmware.bin" would no longer erase the Flash - is this assumption correct?

I am designing a consumer product with an exposed USB Port with the expectation that customers could do a simple "drag-n-drop" to update their code.  Everything I've read, and everything I've been lead to believe about this chip suggested that this capability was possible.  It's very disheartening to now learn that this isn't really possible with this chip without implementing a CRP3-based solution, as any other CRP setting leaves the chip vulnerable to erasure.

Thank you for your help Ping. I look forward to your answers to my questions about both the LPCXpresso example project I've requested, and also your comments about how feasible this new AN11732 method is for the average end user customer to use.

Matt

[mattferrari]

Hi Ping - 

Is it not the case that in CRP1, Sector-0 is NOT supposed to be erased unless ALL sectors are being erased?  Isn't that the whole point of Sector-0, that when using CRP1, Sector-0 is protected and will persist unaltered unless ALL sectors are selected for erasure?  The intent of CRP1 is to allow partial field updates to Flash WITHOUT altering Sector-0.  So I should be able to download a couple sectors of new code WITHOUT affecting Sector-0, isn't that correct?  

The User Manual (Rev 1.3, Section 27.4.2) states for CRP1: 

- Copy RAM to flash command can not write to Sector 0.
- Erase command can erase Sector 0 only when all sectors are selected for erase.

So if I have established CRP1, then via the USB Bootloader I delete "firmware.bin" in Windows Explorer and copy in a new file containing only a few Sectors of new code, Sector-0 should remain as it was, unaltered and unaffected by the update.  It shouldn't be erased, but I am observing that in fact it IS getting erased.

This is what I'm still trying to make sense of.  Can you please explain this discrepancy?  Or if I am still misunderstanding things, please reconcile the statements from Section 27.4.2 and the fact that I am seeing Sector-0 get erased when only a few Sectors are being updated via the USB Bootloader.

The only possible explanation I can think of is that the action of deleting the "firmware.bin" file in Windows Explorer via the USB Bootloader actually has the effect of first deleting ALL the Sectors in Flash, then subsequently, the new file is written into Flash.  Is this what's happening?  But if that is so, then this would completely defeat the whole point of being able to do partial field updates to Flash using the USB Bootloader while preserving Sector-0, which is what I thought CRP1 was all about.  I'm starting to think that deleting "firmware.bin" via the USB Bootloader results in the deletion of all Sectors of Flash.  Is this correct?  It would be really helpful to get clarification on this...

Thanks Ping

[jeremyzhou]

Hi Matt Ferrari,

I've contacted with the AE team for confirming, and let me clarify the 'discrepancy'.

When the target enter the USB ISP mode, the whole flash will be erased when the 'firmware.bin' is deleted and your guess is right.

And one more thing, the ISP command is only available in the UART ISP mode.

I've also attachment a USB Secondary bootloader demo which is suit for LPC113x/2x and you can refer to it for details.
Have a great day,
Ping

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[mattferrari]

Hi Ping, thank you for your reply.  Yes, I read this in the User Manual too.  The reason I've posted is that the description of how CRP1 SHOULD work is not what I'm seeing.  I have also read in some App Notes that CRP1 DOES erase all the flash before writing, so the information is inconsistent.  Here's what I'm seeing:

1) Program CRP for CRP1.

2) Power cycle the chip, enter the bootloader and observe: CRP1 ENABLD at the drive designation.

3) Delete "firmware.bin" and copy over new file which is only a couple sectors in size.

4) Reset chip and observe that instead of running the new code, it just re-enters Bootloader and displays: "CRP DISABLD"

This sequence of events demonstrates that Sector-0 (where CRP is stored at 0x2FC) was in fact overwritten when the "firmware.bin" file was deleted and the small ".bin" file was transferred.

Since not ALL sectors were being written, this shouldn't happen.  Sector-0 (and thus the CRP) shouldn't have been altered because CRP1 was in force.  But Sector-0 was obviously written as evidenced by the CRP change reported at the drive designator after reset.

So I am trying to figure out why I am seeing this.  Why deleting "firmware.bin" and copying in the new code leaves Sector-0 erased.

Can you explain why this would be happening?

Thanks.

[jeremyzhou]

Hi Matt Ferrari,

As I mentioned before, when the "firmware.bin" file was deleted and the small ".bin" file was transferred, it means the  "firmware.bin" file occupied area had been erased and the sector 0 in included in the area which is illustrated in the map file (Fig1).

Have a great day,
Ping

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------