Bootloader from SIOW: error 510 timeout

[dluu13]

I am trying to use the CCS bootloader. I am just putting ex_ccs_bootloader.c onto a PIC24 Curiosity development board.

When I download using SIOW, I get the "Error #510 Timeout while downloading". According to the send dialogue, I have only sent one line from my PC to the PIC before this error.

Here is my setup before the body of the bootloader program:

[dluu13]

I have hooked up the serial lines to a logic analyzer and also opened up the file I am trying to load using HxD (a hex editor).

They do not look alike. Of the three times I measured, only one time did the PIC respond with the XON and XOFF characters.

For reference, the first few lines of my .hex file:

[Ttelmah]

Er. ex_ccs_bootloader.c is not compatible with a PIC24.

The file for a PIC24, is ex_pcd_bootloader.c

Now your board should have the PIC24FJ128GA204, so will need
the #define PIC24FJ enabled in this file and the PIC24HJ remmed out.

I'd get rid of all the fuses controlling the clock, and just use:

#use delay(INTERNAL=32MHz)

The compiler will then automatically perform the clock settings for
this speed.

pcd_bootloader.h, should be the first #include. Before stdio.

[dluu13]

Thanks for the reply. I realized that I made a typo in my original post. I am using ex_pcd_bootloader.c

I have already been using the #define PIC24FJ and also tried #define PIC24FJ_REV2. However, as far as I can tell, those defines are not referenced anywhere. I can comment them all out and everything still compiles.

I have also moved the stdio include to after the pcd_bootloader.h include.

However, this still results in time out.

Just in case this matters, the .hex file I am feeding into SIOW is a program that I made to blink one of the LEDs on the board, and it works on its own.

Thanks for the #delay tip. That also works for the clock set up.

EDIT: Now here's something I don't really understand. See this picture:
Picture link

I have hooked my logic analyzer up to the PIC, looking at the TX and RX lines from the PoV of the computer. So the computer is sending some packets, and most of them have a 0x13 0x11 reply from the PIC as seen on the RX line.

I noticed that all of the send packets that do not get a reply from the PIC are missing the carriage return character at the end.
See these two:
with carriage return
without carriage return

Why does SIOW appear to be sending incomplete messages to the PIC?

[Ttelmah]

Have you moved pcd_bootloader.h to be in front of stdio.h?.

Problem is that pcd_bootloader is needed to correctly locate all routines
having routines loaded before this is setup could give major issues.

[dluu13]

Yes I have tried moving stdio to after the pcd_bootloader.h include, as I stated in previous post.

I originally thought that stdio.h would be needed in front since loader_pcd.c uses getc and putc functions

[Ttelmah]

What happens if you explicitly enable XON/XOFF?.

[dluu13]

I tried that as well, with no effect. I read in another post somewhere that we do not want to enable XON/XOFF in SIOW, because bootloader exe takes care of it.

I'm just wondering why lines sent by SIOW sometimes do not end with the '\r' character, as is expected by the bootloader on the PIC.

[Ttelmah]

OK.
Forget SIOW. What I'm interested in is the handshake settings inside
Windows itself (device manager). Thought going through my head
is that possibly Windows is actually set to use hardware handshaking,
and when the burst of data is coming from the PIC, is possibly
asserting this, which the PIC doesn't know about, so characters then
get lost...
Could explain what you are seeing.

What you 'see' is what Windows has accepted receiving, so if it
decides it's buffer is full, and characters still arrive, these will be lost...

[dluu13]

Windows COM port settings

Thanks for sticking with me. It's got 8N1, 9600 baud, no handshaking.

Thing is that Windows is the one sending the burst of data, and my logic analyzer does not even see the data coming out of the computer, so I guess the PIC will not see it either. I believe it is the computer that is skipping out on the '\r' character. The computer receives the 0x13 0x11 just fine...

[dluu13]

If I understand correctly, SIOW calls on ccsbootloader.exe to do the bootloading sequence right? I notice that the version of ccsbootloader.exe has a different size than the one that I can download on the ccsinfo website.
Do you think siow is interfering somehow?

[Ttelmah]

Problem is I don't use ccsbootloader.
I use their bootloader on some chips, but all I do is set the XON/XOFF
in device manager, and copy the hex file directly to the com port. Nothing
else needed...
So I've never tried with SIOW, or their bootloader program.

[dluu13]

hrmm if I run it from command line, I get this from the debug output:

[Ttelmah]

copy yourfile.hex \\.\COMxx

Where 'xx is the port number 0, 1, 2, etc..
The system just transmits the file using the com port settings configured
in device manager.

[dluu13]

hmm my device manager doesn't let me set the xon xoff chars... as in I don't see a field for me to set that.

EDIT:
So far, the farthest I've gotten is to run ccsbootloader.exe by command line. It does what I described a couple of lines above.

I feel as though something about that bootloader clobbers some of the ROM it's not supposed to.

I have set an LED to turn on when the PIC starts up, and another if it enters bootloader mode. That means that when the bootloader ends, one of the LEDs should turn off. Instead, halfway through the load, both LEDs turn off. Pressing the MCLR button or power cycling will not bring the LEDs back. The only way I can get them back is by flashing the bootloader on again.

So I think there is definitely some fishy stuff going on here, but I don't have the time/knowledge to figure out what at the moment.