PIC24EP512GU810 CCS USB and Microchip Bootloader

[rwalborn]

I have a puzzling problem.
My main application uses the pic24_usb.c with interrupts to communicate. This appears to work fine.

I have the Microchip HID bootloader with remapped IRQ vectors.
If I add My Project to mpLab x lab as a loadable project and run under debug, the USB enumerates fine. If I load the hex file through the booloader it will not enumerate. If I add an application image to the bootloader project, it will also not enumerate. I verified that I am getting the USB interrupts. It generates a break point.

I am using a 4 mhz crystal for both the system and USB with the right setup for the USB clock.

Does anyone have any suggestions?


A follow up. i dropped the USB interrupt and got it to work. There may be a bug in the CCS PIC24_usb.c routine when using interrupts and this processor. Anyhow, without USB interrupts I can load the firmware image in Mplab x and update the firmware thru USB and have the USB connect.

I am still using RS232 interrupts which don't seem to present a problem.

I finally tracked down the source of my problem. I have a a small char array stored in rom that has the firmware version etc.

When the project is loaded in debug this doesn't present a problem . However when the image is loaded , the problem presents itself. By comparing the two firmware imaged downloaded to the microcontroller I found they didn't match .( the check sums were different. The hex codes were different by 4 bytes. It turns out that the last character in the rom statement were over writing part fo the RS-232 interrupt routine , which caused really weird behavior.

[jeremiah]

What method are you using to map the USB ISR in your application code? My first guess is that either you aren't correctly mapping it or the bootloader you are using doesn't map it correctly.

Are you using the #build directive and if so, can you post what it has in it?

[rwalborn]

I figured out the problem and found a bug in the 5.044 software.
I put a #rom statement in the code that has the firmware revision information. That information is read by the firmware bootloader so the user knows what is installed and if it requires updating.

Anyhow, if loaded the processor with the debug and the bootable debug image and read them back out and stored them in hex files. I used the compare file utility to compare the two files and the check sums did not match. After scrolling through the files I found that 2 bytes were different. Tracing back through the listing file I discovered that the last two bytes of the rom statement were overwriting a getc call in an interrupt service routine. Which messed up everything. Adding a extra space at the end of the string stopped this from occurring. Why it worked in debug mode is still a mystery.