USB Bootloader - bug fix & licensing question

[lpcware]

Content originally posted in LPCWare by Rob65 on Mon Nov 21 01:37:23 MST 2011
NXP provided a USB Bootloader example written for the Keil stack and Keil compiler environment. Code Red did a nice job converting this into an LPCXpresso example with the LPCUSB stack.

The original code is (c) Keil Software and may only be used with a valid license for compatible versions of the KEIL software development tools.
The Code Red version is partly (c) Code Red, all rights reserved.

My question is: Am I allowed to use this code for my own board, can I give this code (source and binary) to customers when they buy a board (actually I just want to place the code on my website, available for anyone who wants it) ?

Next, I also fixed a small bug in the code. The USB bootloader could not be used to program the smaller flash blocks (blocks 4..16). On close examination I noticed there was a verry funny 'bug' :

In main_bootloader.c on line 71, it reads: if( n == ((NO_OF_CLUSTERS+2)-1) ) but the original NXP code reads if( n == (NO_OF_CLUSTERS-1) ).

Changing this back to the NXP statement, together with a change of the BLOCKS_PER_CLUSTER define in disk.h to 2 (instead of 64) results in a bootloader that works with USER_START_SECTOR (sbl_config.h) set to 4.
Note that I also removed the LCD stuff used by the RDB1768 board - I did not check the start sector with the LCD code enabled.

Regards,[INDENT]Rob
[/INDENT]

[lpcware]

Content originally posted in LPCWare by Rob65 on Wed Nov 23 10:38:12 MST 2011

---

Quote: CodeRedSupport
we are happy for you to post your own version on your website, as long as the Code Red copyright message remains intact and you include acknowlegdement and a pointer back to our website in your docs.

---

Thanks, I'll check to make sure there is an acknowledgement in the docs.

Of course your copyright message is still intact and it goes without saying that there should be a note also that I changed things ...

---

Quote:

With regards to your "bug fix", I would suggestion caution in undoing the change made in the Code Red bootloader, compared to the NXP original. I can't remember the full details, as this work was done nearly 2 years ago, ...

---

Looks like you have done more testing than I have ...
I tried different programs, smaller and larger ones and this all worked as expected - But I never tried to write multiple files or even looked at what happens when I try to write to a flash that is already partly filled.
I always deleted the old file before writing a new one and that seems to works OK.

I will add some warning notes about this.

Regards,[INDENT]Rob[/INDENT]

[lpcware]

Content originally posted in LPCWare by CodeRedSupport on Wed Nov 23 08:03:26 MST 2011
With regards to copyright messages, then if a file has a Code Red copyright message in it, then we are happy for you to post your own version on your website, as long as the Code Red copyright message remains intact and you include acknowlegdement and a pointer back to our website in your docs.

I believe that NXP has the same policy with regards to leaving the copyright message intact  - as posted in this thread....

http://knowledgebase.nxp.com/showthread.php?t=2514&langid=2

Your ability to post code with any other copyright message in it will depend upon the terms set out by the originator of those files.

With regards to your "bug fix", I would suggestion caution in undoing the change made in the Code Red bootloader, compared to the NXP original. I can't remember the full details, as this work was done nearly 2 years ago, but from what I can remember I made the change because without my "fix" the host PC OS can report free space in the flash when there isn't any.

In addition, you need to be careful when extending the memory used as the flash drive down below the 64KB location. Doing so means that you end up with a mixture of 4KB and 32KB sectors being used. I seem to recall seeing some issues where by file writes/deletes can behave incorrectly or seemingly unpredictably, particularly when the files sit in the middle of flash sectors (thus you are likely to only see this if you actually try writing multiple files into the flash).

I fixed this in the RDB1768 version that we provide today by moving to a model where I only use the 32KB flash sectors, and tell the host PC OS that the sector size is 32KB. I did do some initial work to extend the flash memory used down into the 4KB sectors, but unfortunately never finished this off.

Regards,
CodeRedSupport