| View previous topic :: View next topic |
| Author |
Message |
Damaso
Joined: 07 Nov 2012
Posts: 11
|
| Pic24F USB bootloader |
 Posted: Wed Nov 07, 2012 5:02 am |
 |
|
I'm not sure if this has been answered before but I couldn't find a topic about this question. I'm working with a PIC24FJ128GB106 and I need to program a USB bootloader for it.
Does anyone have a valid code that I can use or point me in the direction I have to modify an existing code? |
|
 |
Bill24
Joined: 30 Jun 2012
Posts: 45
|
| Re: Pic24F USB bootloader |
| Posted: Wed Nov 07, 2012 6:14 am |
|
|
| Damaso wrote: | I'm not sure if this has been answered before but I couldn't find a topic about this question. I'm working with a PIC24FJ128GB106 and I need to program a USB bootloader for it.
Does anyone have a valid code that I can use or point me in the direction I have to modify an existing code? |
I have posted my PIC24 boot loader code. Ref :
http://www.ccsinfo.com/forum/viewtopic.php?t=48550
This is for a PIC24FJ256GB108. If you compare this with the CCS example you will see differences relating to flow control. The CCS example uses xon/xoff in the function load_firmware () . My code uses a command method as shown in my function check_for_usb_data () which can be stripped out.
The other functions are:
atoi_b16 () - same as CCS example
init_flash_page_0 () - This is needed as flash must be erased before it is written to. Flash page 0 contains the restart vector and interrupt tables.
If possible avoid using interrupts in your boot loader as the will need to be revectored when your application is loaded. My implementation was derived from a USB version rather than RS232. To get around the interrupt clash, the boot loader uses the alternate interrupt table and the application uses the main table.
load_firmware ()
This is derived from the CCS example with some additions for the PIC24 architecture as shown by the comments.
This code has worked reliably so far (we have around a 1000 units using it) .
It is a bit slow though. The reason being each line of HEX to be downloaded is 32 bytes. However the flash page size for the PIC25 is much larger. To speed things up I could have buffered several lines of HEX before writing to flash.
However as it works I am loathe to 'fix' it.
Hope this helps. |
|
|
Damaso
Joined: 07 Nov 2012
Posts: 11
|
|
| Posted: Wed Nov 07, 2012 7:21 am |
|
|
I've seen in your code that you are mapping 2 UARTs:
| Code: | #define IRDA_RCV PIN_D14
#define IRDA_XMIT PIN_D15
#define TEST_RCV PIN_D12
#define TEST_XMIT PIN_D8 |
| Code: | // Maps UART1 and UART2 RX and TX to pins D14, D15, D12 and D8 respectively*/
#pin_select U1TX = IRDA_XMIT
#pin_select U1RX = IRDA_RCV
#pin_select U2TX = TEST_XMIT
#pin_select U2RX = TEST_RCV |
Are they used for the communication between PC and PIC? I'm a bit lost trying to figure out how are you managing the usb communication.
Do I need to use a specific linker for the program (not the bootloader)? |
|
|
Bill24
Joined: 30 Jun 2012
Posts: 45
|
|
| Posted: Wed Nov 07, 2012 8:42 am |
|
|
| Damaso wrote: | I've seen in your code that you are mapping 2 UARTs:
| Code: | #define IRDA_RCV PIN_D14
#define IRDA_XMIT PIN_D15
#define TEST_RCV PIN_D12
#define TEST_XMIT PIN_D8 |
| Code: | // Maps UART1 and UART2 RX and TX to pins D14, D15, D12 and D8 respectively*/
#pin_select U1TX = IRDA_XMIT
#pin_select U1RX = IRDA_RCV
#pin_select U2TX = TEST_XMIT
#pin_select U2RX = TEST_RCV |
Are they used for the communication between PC and PIC? I'm a bit lost trying to figure out how are you managing the usb communication.
Do I need to use a specific linker for the program (not the bootloader)? |
This boot loader was based on a similar boot loader that used USB instead of RS232. Our Equipment had the torture of boot loading from a PC via USB to a PIC. The downloaded application would then route further USB packets from the PC via RS232 to a second PIC.
| PC | ----USB --- | PIC1 |-----RS232 ----| PIC 2 |
Most of the code was identical and so the same file was used for boot loaders.
The posted code is the boot loader for PIC 2 over RS232. As it also has a debug port, two RS232 connections are initialized in the code (one called TEST).
You do not need a separate linker file for the application BUT you must ensure that the boot loader jumps to the start of you downloaded application. We compiled all applications to start from a known location e.g we use #ORG 0x200, 0x8000 prior to main().
The PC application which we wrote had flow control. This is needed as a line of HEX code is sent to the PIC, the PC then waits. The PIC decodes the HEX code, erases a block of flash specified by the address byte in the line of HEX code, programs the flash and does a compare. If all ok then a message is sent back to the PC to signal it to send the next line of HEX. The CCS application uses xon/xoff to achieve flow control. |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
