LPC1700 secondary USB bootloader

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

LPC1700 secondary USB bootloader

1,162 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by renan on Wed Jan 27 04:36:41 MST 2010
Is there any change someone ported the code described in AN10866 application note to Code Red RDB1768 board?

AN10866 LPC1700 secondary USB bootloader
http://www.nxp.com/acrobat_download/applicationnotes/AN10866.pdf

Renan
0 Kudos
14 Replies

798 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by CodeRedSupport on Thu Oct 13 06:51:04 MST 2011
I suspect that you have failed to follow the steps in full, though without your actual project it is hard to say which one(s).

I would suggest that start off by looking at one of the supplied RDB1768 examples that are prebuilt to work with the bootloader. These have project names ending with "[B][FONT=Courier New][SIZE=2]_64K[/SIZE][/FONT][/B]". Compare how these projects are set up to the notes in the bootloader readme.

By the way - I would suggest that you create a new forum thread if you want more help. This rather old thread is really on a completely different level (someone trying to make major changes to the bootloader).

Regards,
CodeRedSupport
0 Kudos

798 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by james on Thu Oct 13 02:33:51 MST 2011
Hi, I tried the [SIZE=2]RDB1768cmsis2_usb_bootloader example downloaded from red-code bundle. I compiled it and everything works fine, after that I tried to create the binary file by following exactly to the instructions written in the read.txt, however i encountered a few errors.[/SIZE]
[SIZE=2][/SIZE]
[SIZE=2]I tested it on another example also included in the bundle : easyweb[/SIZE]
[SIZE=2][/SIZE]
[SIZE=2]1) [SIZE=2]d.exe: cannot open linker script file RDB1768cmsis_EasyWeb_lib.ld: No such file or directory[/SIZE][/SIZE]
[SIZE=2][/SIZE]
[SIZE=2]I copied the lib and mem file into the debug folder and compile, and got this error.[/SIZE]
[SIZE=2][/SIZE]
[SIZE=2]2) [SIZE=2][COLOR=#ff0000][SIZE=2][COLOR=#ff0000]d.exe: Linker CRP Enabled, but no CRP_WORD provided within application[/COLOR][/SIZE][/COLOR][/SIZE][/SIZE]
[SIZE=2][COLOR=#ff0000][/COLOR][/SIZE]
[SIZE=2][COLOR=black]I followed the solutions given in : http://knowledgebase.nxp.com/showthread.php?t=1586[/COLOR][/SIZE]
[SIZE=2][/SIZE]
[SIZE=2]unchecked the CRP and the 2lines are already included but the error still exist.[/SIZE]
[SIZE=2][/SIZE]
[SIZE=2]Anyone tried this example could you give any advise on how to advance from here onwards?[/SIZE]
[SIZE=2][/SIZE]
[SIZE=2][/SIZE]
0 Kudos

798 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by CodeRedSupport on Tue Aug 24 04:47:58 MST 2010

Quote: renan
If I change BLOCKS_PER_CLUSTER to 8, the algorithm to create the FAT table would change? If so, how?


I don't think so (though I haven't tested) - as this should all be handled automatically by the changes to the defines.

Regards,
CodeRedSupport
0 Kudos

798 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by renan on Tue Aug 24 04:20:51 MST 2010

Quote: CodeRedSupport

If you wanted to move down to using the 4K sectors in the bottom of 64KB of the flash, then you would need to change BLOCKS_PER_CLUSTER in disk.h from 64 to 8.

Note that when you set the size of the flash drive, it appears to need to be 2 flash sectors in size (so a multiple of 8KB if you are using the 4KB sectors, or 64KB if you are using the 32KB sectors).



If I change BLOCKS_PER_CLUSTER to 8, the algorithm to create the FAT table would change? If so, how?

Renan
0 Kudos

798 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by CodeRedSupport on Tue Aug 24 03:02:09 MST 2010

Quote: bmentink
It's ok I found it.

I did a build with the LCD stuff out and it came to ~6K in a release build.

However, I will keep to the scheme of starting at 64k for the main code as this gives me 192k available for the LPC1765 and with the bootloader only taking 6K, I have 58K available above the bootloader for other storage.


You will need to modify the value for MAX_USER_SECTOR in sbl_config.h to change the end of the flash used for the "flash drive". Similarly, if you wanted to change the start, then you would need to change USER_START_SECTOR. 

If you wanted to move down to using the 4K sectors in the bottom of 64KB of the flash, then you would need to change BLOCKS_PER_CLUSTER in disk.h from 64 to 8.

Note that when you set the size of the flash drive, it appears to need to be 2 flash sectors in size (so a multiple of 8KB if you are using the 4KB sectors, or 64KB if you are using the 32KB sectors).

Quote:

Which brings me to some other USB/Flash questions:

1. Can you call the ISP programming functions in the bootloader, from my applications code? If so, how to you get the address of these functions?

I would suggest that the simplest way of doing this would be to use function pointers. Create a table in the bootloader at a fixed address which contains the address of the functions (you'll need to create your own linker script to place the table - http://lpcxpresso.code-red-tech.com/LPCXpresso/node/31). Then in your application code, you can load the address of the appropriate function from the table and jump to it.


Quote:

And slightly off topic .. sorry..

2. With the USB stack, can I have a storage class and a CDC serial class active at the same time?

3. In the CDC class driver, can I have more than one instance (i.e more than one serial device ..)

Theorectically I believe these should be possible, though note that LPCUSB is an open source stack and we can only provide fairly limited advice on its use. I would suggest doing a google for something like "LPCUSB cdc mass storage". The first hit I get is...
http://tech.groups.yahoo.com/group/lpc2000/message/47881

Regards,
CodeRedSupport
0 Kudos

798 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by bmentink on Mon Aug 23 18:49:32 MST 2010
It's ok I found it.

I did a build with the LCD stuff out and it came to ~6K in a release build.

However, I will keep to the scheme of starting at 64k for the main code as this gives me 192k available for the LPC1765 and with the bootloader only taking 6K, I have 58K available above the bootloader for other storage.

Which brings me to some other USB/Flash questions:

1. Can you call the ISP programming functions in the bootloader, from my applications code? If so, how to you get the address of these functions?

And slightly off topic .. sorry..

2. With the USB stack, can I have a storage class and a CDC serial class active at the same time?

3. In the CDC class driver, can I have more than one instance (i.e more than one serial device ..)

Many Thanks,
Bernie
0 Kudos

798 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by bmentink on Mon Aug 23 12:40:37 MST 2010
Thanks for that, it is all clear now.

Can you point me to the are of code that has the sector size defined and what sectors to start/end at my flash drive? Thanks.

I will strip out all the LCD stuff and see what I can get the size down too.

Cheers,
Bernie
0 Kudos

798 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by CodeRedSupport on Mon Aug 23 01:28:59 MST 2010

Quote: bmentink
Tell me, why does this port of the NXP secondary bootloader take up 64K !!,
the original only took two sectors (8K) ..
Using 64K makes it worthless for the smaller parts ..


The code for the RDB1768 usb secondary bootloader does not actually consume all of the first 64KB of the LPC1768 flash. It ought to be possible to fit the bootloader code into 8KB or so - particularly if the LCD related code and data were removed. However there were a number of reasons why the "flash drive" does start at 64KB. In particular....


[LIST]
[*]The project that the secondary bootloader spun out of from was actually a much more complex system, and this did actually consume ~60KB of the flash for its code. When the bootloader was developed, the same "flash drive" settings were used as the more complex system - as the target was the RDB1768 board, we did not actually consider LPC17xx parts with smaller amounts of flash.
[/LIST]

[LIST]
[*]The LPC17xx family has multi-sized flash sectors. Below 64KB, the flash has a 4KB sector size, from 64KB upwards the flash sectors are 32KB in size. However when treating the flash as a FAT flash drive, a fixed sector size has to be chosen. Having a drive sector size that is smaller than the actual sector size of the flash can cause problems, particularly if you want the flash drive to act as a real flash drive that can have multiple files written and deleted. Thus because of the requirements we had for some internal work, we chose to treat the drive sector size as 32KB, and thus to start it at 64KB in the flash, as that was where the flash sector sizes switched to 32KB in size.
[/LIST]

Note, that it should be fairly straghtforward to convert the RDB1768 bootloader to a smaller LPC17xx part by using the flash from, say, 16KB to 64KB as your "flash drive", and reducing the drive sector size to 4KB.

Regards,
CodeRedSupport
0 Kudos

798 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by bmentink on Fri Aug 20 14:31:28 MST 2010

Quote: CodeRedSupport
Renan,

The RDB1768 usb bootloader can now be downloaded as part of the newly updated RDB1768cmsis examples at:

  http://support.code-red-tech.com/CodeRedWiki/RDB1768Support

Regards,

CodeRedSupport



Tell me, why does this port of the NXP secondary bootloader take up 64K !!,
the original only took two sectors (8K) ..
Using 64K makes it worthless for the smaller parts ..

Cheers,
Bernie
0 Kudos

798 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by CodeRedSupport on Thu Feb 04 14:01:46 MST 2010
Well in principal, it certainly should be possible!

You would probably want to use an embedded filing system like EFSL (http://efsl.be/) or FatFs (http://elm-chan.org/fsw/ff/00index_e.html) to read your data off the file system on your SD card. As you read the data off, you could then use the IAP code already in the bootloader to write the data to the LPC1768's embedded flash.

The bottom layer of the RDB1768/lpcusb mass storage example (the code for accessing the SD card over SPI) is actually based on the bottom layer of EFSL, so that should you a good head start on porting efsl over.

We have actually done some initial work on writing a new example showing the use EFSL on the RDB1768. However this isn't likely to be finished/released in the immediate future, so you would almost certainly find you can get your own EFSL port done before our example appears.

Finally, the RDB1768 USB hidmouse provides example code  for reading the various joystick values.

Best regards,

CodeRedSupport
0 Kudos

798 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by renan on Thu Feb 04 12:07:00 MST 2010
Thanks for that.

I have another question:

I need to divide the flash in 3 sectors:
1. 2 bootloader - ~ 12k
2. user code      - ~ 444k
3. data              - ~56k
ps.: size is +- like this. I'm not sure yet, but it is just to give an idea of what I want.

When pressing p0.6 (joystick click), it works as it should do in the example, but when I press p0.1 (joystick right) it would  copy the data from the SD Card to the 3º sector.

Is this possible, right?

Thanks,
Renan
0 Kudos

798 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by CodeRedSupport on Fri Jan 29 06:20:17 MST 2010
Renan,

The RDB1768 usb bootloader can now be downloaded as part of the newly updated RDB1768cmsis examples at:

  http://support.code-red-tech.com/CodeRedWiki/RDB1768Support

Regards,

CodeRedSupport
0 Kudos

798 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by renan on Wed Jan 27 07:49:28 MST 2010
Thanks
0 Kudos

798 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by CodeRedSupport on Wed Jan 27 06:51:32 MST 2010
Renan,

Code Red have a usb bootloader for the RDB1768, similar to the one described in NXP's apps note, in development at the moment. We expect to release this within the next week. We will post again once it is available.

Regards,
 
CodeRedSupport
0 Kudos