pic24fj256gb110 [solved]

[kyu]

I'm currently getting a wrong pic detected error message saying it detected 254/selected 243 when I try to check for BL. I've commented out all the other devices so I know that the DEVICEID should be 243. Does this error at least mean that I'm communicating with the PIC?

I'm using PPS with pin39=UART1_TX and pin40=UART1_RX. I checked the datasheet to make sure that I was writing to the right registers for the PPS.

I've attached my PIC project. Any suggestions would be a great help.

TIA

[Mikael Gustavsson]

The attached files are identical to the official release files...
Yes, you've got communication.

[kyu]

Thanks for responding. I've attached the firmware with my current settings(I don't think copying worked correctly earlier). I haven't gotten a chance to alter my application project to protect the bootloader yet(although it doesn't have any data written to bootloader memory locations).

When I insert the .hex file into the GUI it gives me a warning saying that .hex file has content that will overwrite the bootloader. Reading through your documentation this may be caused by the GUI saying that it's not detecting the correct device. I've attached the .hex file warning as well as the error message I'm getting. Any suggestions?

ps. I'm using a Windows 7 would that be a problem?

[Mikael Gustavsson]

Getting time out is not a good sign.
I suggest you disable high baud rates and try a lower baud rate, such as 9600 to start with.

[kyu]

I've reduced the baudrate and I believe I never had communication with the PIC. I'm not sure what the issue would be. I did however notice that when in debug mode, when I try to run the project the program halts almost immediately after I run it returning back to address location 0x00. If I needed the pins to be digital what changes need to be made?

Would the GUI still be able to check for bootloader even after the default 3sec delay jump to user application?

[Mikael Gustavsson]

"If I needed the pins to be digital what changes need to be made?"
Section 21 in the data sheet.

Have you verified communication with an application without the bootloader?

[kyu]

Yes I have a program that uses the uart. does the uart have to be dedicated to just the bootloader? I would like to use the same uart for my application

[Mikael Gustavsson]

No it doesn't need to be dedicated.

"I'm using a Windows 7 would that be a problem?"
Shouldn't be a problem.

"Would the GUI still be able to check for bootloader even after the default 3sec delay jump to user application?"
No.

What output do get from the gui?
Do you reset the device within 2-3 seconds after pressing download?

[kyu]

well for now I'm not trying to download I'm just checking to see if it can recognize the bootloader. I'll see If the reset works after "Check for BL"

[kyu]

yea that didn't work either. Do I need to make sure that the .hex file doesn't have memory in the bootloader location before trying to "check for bl"? how can I protect the bootloader memory location in my application so that program memory is not used in those locations?

[Mikael Gustavsson]

No you don't, the gui will tell if there's a problem.

You don't need to protect the memory. If you still want to, reserve the memory in the linker script.

If you have an oscilloscope available, check the signals and make sure the baud rate is ok.
If the uart works in the application, compare the initialization code in the bootloader.