CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

Bootloader from SIOW: error 510 timeout
Goto page 1, 2  Next
 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
dluu13



Joined: 28 Sep 2018
Posts: 395
Location: Toronto, ON

View user's profile Send private message Visit poster's website

Bootloader from SIOW: error 510 timeout
PostPosted: Tue Mar 31, 2020 1:31 pm     Reply with quote

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:
Code:
#include <24FJ128GA204.h>

#case

#FUSES NOWDT, NODEBUG, NOWRT, NOPROTECT, NOJTAG, ICSP1
#FUSES NOLVR, NOBROWNOUT, NOIOL1WAY, NODSBOR, NODSWDT
#FUSES NOALTCMPI, FRC_PLL, PLL_FROM_FRC, PLL8X

#PIN_SELECT U3RX=PIN_B10
#PIN_SELECT U3TX=PIN_B12

#define BOOTLOADER_STREAM PC

#use delay(clock=32MHz)
#USE RS232(BAUD=9600, UART3, BITS=8, PARITY=N, STOP=1, STREAM=PC, ERRORS)//, RECEIVE_BUFFER=128) //Text through the UART
#define PUSH_BUTTON PIN_C9

#define _bootloader
//#define BOOTLOADER_MODE2X

#include <stdio.h>
#include <pcd_bootloader.h>
#include <loader_pcd.c>


Here is the body of the code:
Code:

void application(void)
{
    // unchanged from CCS
}

void main(void)
{
    // unchanged from CCS
}

#int_default

void isr(void)
{
    // unchanged from CCS
}


I am sure that my oscillator and uart setups are correct. I am able to correctly send/receive on the PIC. In SIOW, I have disabled XON/XOFF, so that should only be on during bootloading.

Is there something that I am overlooking?
dluu13



Joined: 28 Sep 2018
Posts: 395
Location: Toronto, ON

View user's profile Send private message Visit poster's website

PostPosted: Tue Mar 31, 2020 3:17 pm     Reply with quote

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:
Code:
3A 30 38 30 30 30 30 30 30 34 45 30 32 30 34 30
30 30 30 30 30 30 30 30 30 41 34 0D 0A 3A 30 34
30 30 34 38 30 30 30 30 30 32 30 30 30 30 42 32
0D 0A 3A 31 30 30 34 30 30 30 30 34 32 30 30 46


RX line of the PIC:
Code:
PIC RX                                              |   PIC TX
                                                    |
3A 30 30 30 30 30 34 30 30 30 30 30 30 30 30 41     |
3A 38 30 30 30 34 30 30 34 30 30 30 30 30 34        |
15                                                  |
                                                    |
3A 30 30 30 30 30 30 30 34 30 30 30 30              |
3A 30 30 30 34 45 32 30 30 30 30 30 41              |
15                                                  |
                                                    |
3A 30 30 30 30 30 34 32 34 30 30 30 30 30 41 0D     |   13 11
3A 30 30 30 30 45 30 34 30 30 30 30                 |
3A 30 38 30 30 45 30 30 30 30 30 30 41 34           |
15                                                  |


Furthermore, this does not seem to match my hex file...
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Wed Apr 01, 2020 1:00 am     Reply with quote

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



Joined: 28 Sep 2018
Posts: 395
Location: Toronto, ON

View user's profile Send private message Visit poster's website

PostPosted: Wed Apr 01, 2020 6:39 am     Reply with quote

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?


Last edited by dluu13 on Thu Apr 02, 2020 6:33 am; edited 1 time in total
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Wed Apr 01, 2020 7:55 am     Reply with quote

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



Joined: 28 Sep 2018
Posts: 395
Location: Toronto, ON

View user's profile Send private message Visit poster's website

PostPosted: Wed Apr 01, 2020 8:05 am     Reply with quote

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



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Wed Apr 01, 2020 10:24 am     Reply with quote

What happens if you explicitly enable XON/XOFF?.
dluu13



Joined: 28 Sep 2018
Posts: 395
Location: Toronto, ON

View user's profile Send private message Visit poster's website

PostPosted: Wed Apr 01, 2020 10:27 am     Reply with quote

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



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Wed Apr 01, 2020 11:57 pm     Reply with quote

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



Joined: 28 Sep 2018
Posts: 395
Location: Toronto, ON

View user's profile Send private message Visit poster's website

PostPosted: Thu Apr 02, 2020 6:36 am     Reply with quote

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



Joined: 28 Sep 2018
Posts: 395
Location: Toronto, ON

View user's profile Send private message Visit poster's website

PostPosted: Thu Apr 02, 2020 6:40 am     Reply with quote

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



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Thu Apr 02, 2020 6:54 am     Reply with quote

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



Joined: 28 Sep 2018
Posts: 395
Location: Toronto, ON

View user's profile Send private message Visit poster's website

PostPosted: Thu Apr 02, 2020 7:40 am     Reply with quote

hrmm if I run it from command line, I get this from the debug output:
Code:
Transmit:
;HELLO[0D][0D]

Receive:
[13][06][11][13][11]

Transmit:
:080000004E02040000000000A4[0D]

Receive:
[13][06][11]

Transmit:
:0400480000020000B2[0D]

Receive:
[13][06][11]

Transmit:
:100400004200F8003600F8005400F800801F780021[0D]

Receive:
[13][06][11]

Transmit:
:10041000200020000C000900B01F78008121A900F5[0D]

Receive:
[13][06][11]

Transmit:
:100420008521AA008500A900A00120000C00090078[0D]

Receive:
[13][06][11]

Transmit:
:100430004F1078004F0078005400F9003600F900A2[0D]

Receive:
[13][06][11]

Transmit:
:100440004200F900004006000000E0004220AF003A[0D]

Receive:
[13][06][11]

Transmit:
:10045000040037007B3E0900000000000000E900B6[0D]

Receive:
[13][06][11]

Transmit:
:10046000FCFF3A00000006005E22EF0004E22400D8[0D]

Receive:
[13][06][11]

Transmit:
:10047000D412880004012800F4128800803E200075[0D]

Receive:
[13][06][11]

Transmit:
:10048000240202000000000081E0A9004220EF00E9[0D]

Receive:
[13][06][11]

Transmit:
:1004900081E0A8009500A800000006000F78220067[0D]

Receive:
[13][06][11]

Transmit:
:1004A000F07F220020A0B7000000000081E0A8003B[0D]

Receive:
[13][06][11]

Transmit:
:1004B0008821EF009221EF009C21EF000028EF003F[0D]

Receive:
[13][06][11]

Transmit:
:1004C000340202000000000064020400000000008A[0D]

Receive:
[13][06][11]

Transmit:
:0804D0000020EF000040FE00D7[0D]

Receive:
[13][06][11]

Transmit:
:020000040002F8[0D]

Receive:
[13][06][11]

Transmit:
:10AFF0003F7BFF00FFE6FF00FBB1FF003F3FFF008C[0D]

Receive:
[13]

Transmit:
:10AFF0003F7BFF00FFE6FF00FBB1FF003F3FFF008C[0D]


It appears to get farther along than when I use SIOW.
At the end, I get a message that says PIC stopped responding. Also it appears that my bootloader is now corrupt...

Can you explain how you "copy paste" into the com port?
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Thu Apr 02, 2020 1:10 pm     Reply with quote

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



Joined: 28 Sep 2018
Posts: 395
Location: Toronto, ON

View user's profile Send private message Visit poster's website

PostPosted: Thu Apr 02, 2020 1:18 pm     Reply with quote

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.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group