| View previous topic :: View next topic |
| Author |
Message |
evan
Joined: 02 Apr 2012
Posts: 22
|
| Loader fun! |
 Posted: Thu Jul 23, 2015 3:15 pm |
 |
|
Hi all,
I'm struggling with a loader issue on PIC16LF1519. I've updated my CCS compiler just today (Version 5.048)
Because my application communicates using a GSM modem, I decided not to have a bootloader, but to simply jump into the loader (located at the end of ROM) from the main program as required. I stop global interrupts and watchdog first, then call load_program() using the CCS example loader.c which has worked for me in the past.
The only change I have made to loader.c is to add my #use rs232 line after the #org, to ensure the loader it has it's own copy. I also increased the loader size to 0x3ff to allow for that.
I get the ACK and XON/XOFF responses after every line, so it's not crashing.
Anyway, after loading, the chip is dead, even if I load a very small "hello world" program. The MPLAB tools aren't very useful in comparing the memory but certainly I can see changes after loading.
Is there anything anyone can think of that I might be doing wrong? Any advice or ideas to debug this would be appreciated. |
|
 |
temtronic
Joined: 01 Jul 2010
Posts: 9241
Location: Greensville,Ontario
|
|
| Posted: Thu Jul 23, 2015 4:46 pm |
|
|
| did this setup work before you upgraded the compiler ? |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Thu Jul 23, 2015 5:20 pm |
|
|
| Quote: | | even if I load a very small "hello world" program |
What if you load a very small blinking LED in while() loop program ?
If it works, that would tell you if the problem is UART related. |
|
|
evan
Joined: 02 Apr 2012
Posts: 22
|
|
| Posted: Thu Jul 23, 2015 5:21 pm |
|
|
Temtronic, no, that's why I upgraded (after reading some comments here about flash write problems with the version I had!)
PCM programmer: the small test program .hex works fine if I load it using Pickit directly.
I've just done a little more debugging. It seems that the first line of the hex file gets written, and the rest not (despite being ACKed).
When I look closer, it seems that this line of loader.c
// Only process data blocks that start with ':'
if (rBuffer[0].buffer[0] == ':')
is seeing 0x0A (LF) in the first byte of the buffer, instead of ':' !
What on earth is going on?
I am using Realterm to send (with serial cable from PC). I've used that before with the CCS loader many times without problems.
Puzzled. |
|
|
ckielstra
Joined: 18 Mar 2004
Posts: 3680
Location: The Netherlands
|
|
| Posted: Fri Jul 24, 2015 5:14 am |
|
|
Sounds like the common Microsoft versus 'rest of the world' convention on line endings. Microsoft uses CR/LF, rest of the world uses CR only.
Just a guess, but I see two potential problem causes:
1) In many terminal emulator programs you can configure how a newline is sent, i.e. as a bare CR or as CR/LF. Try setting to the first option.
2) Perhaps the hex-file contains lines ending with CR/LF where the loader expects CR only. |
|
|
RF_Developer
Joined: 07 Feb 2011
Posts: 839
|
|
| Posted: Fri Jul 24, 2015 5:32 am |
|
|
| ckielstra wrote: | | Sounds like the common Microsoft versus 'rest of the world' convention on line endings. Microsoft uses CR/LF, rest of the world uses CR only. |
Can't really lay this one at Microsoft's door, unfortunately. It's more like the Unix vs. Rest of the World. Unix, and related variants, uses LF, pretty much everything else, including stuff way before Microsoft, uses CR/LF.
No systems that I know of ever used LF/CR (though I still have to fix PIC code written by someone, err, some pratt that did... and they used it at the start of a new line rather than as a terminator of an old one, which causes confusion and delays), it was always CR/LF (the reason often quoted being that in the mechnical days, it took longer for the printhead/carriage to go back to the start of a line than it took to wind the paper on a line, so you had to do the CR - Carriage Return - first, to get that going, then the LF - Line Feed. By the time the LF was done, the printhead was positioned ready to start the new line) Unix went its own way be having just a line feed, leaving it up to the peripheral to interpret that as it needed to. I've never seen any system that just used CR as an end of line/terminator; though they might have existed.
The key to interpreting it is to treat CR as white space - padding at the end of a line, if its used at all - and just look for LF. That way both Unix-style (LF only) and everyone else's style (CR/LF) work much the same way. IBM, of course, being IBM, historically, didn't use ASCII at all. |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9241
Location: Greensville,Ontario
|
|
| Posted: Fri Jul 24, 2015 8:12 am |
|
|
I had a 'FORTH' system that used LF/CR not the 'MS standard' of CR/LF.
That caused me some grief until I finally saw what was going on with a hex dump ! easy enough to fix ONCE you actually see the data stream.
Bottom line.. don't take anything at face value !
Jay |
|
|
ckielstra
Joined: 18 Mar 2004
Posts: 3680
Location: The Netherlands
|
|
| Posted: Fri Jul 24, 2015 3:57 pm |
|
|
| Quote: | | The key to interpreting it is to treat CR as white space - padding at the end of a line, if its used at all - and just look for LF. That way both Unix-style (LF only) and everyone else's style (CR/LF) work much the same way. |
That would have been the smart way. Not how CCS is doing it. I haven't tried the file sending feature of Siow, but it looks like we have here one of those rare cases where CR is used without LF.
Here a small part of loader.c | Code: | while (!done) // Loop until the entire program is downloaded
{
buffidx = 0; // Read into the buffer until 0x0D ('\r') is received or the buffer is full
do {
buffer[buffidx] = getc();
} while ( (buffer[buffidx++] != 0x0D) && (buffidx <= BUFFER_LEN_LOD) ); |
The lines are read until a 0x0D (CR) is encountered. When a LF is following it will be treated as first byte of the new line. Exactly what Evan is experiencing.
Of course you are free to modify loader.c to suit whatever your needs are. Here a modified version (untested) that accepts both CR and CR/LF line endings. If it is true that Siow only sends LF, then this version fails. | Code: | while (!done) // Loop until the entire program is downloaded
{
int8 temp;
buffidx = 0; // Read into the buffer until 0x0A ('\n') is received or the buffer is full
do {
temp = getc();
if (temp != 0x0D) // ignore CR character (0x0D), will make the bootloader accept Windows and Linux style line endings.
{
buffer[buffidx++] = temp;
}
} while ( (temp != 0x0A) && (buffidx <= BUFFER_LEN_LOD) ); |
|
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9241
Location: Greensville,Ontario
|
|
| Posted: Fri Jul 24, 2015 4:06 pm |
|
|
just a tip..
IF ( when ) you do modify loader.c be sure to name YOUR version as my_loader.c. Nothing is more frustrating than destroying the ORIGINAL version of working code ! Don't ask how I KNOW that, please.....
Jay |
|
|
gpsmikey
Joined: 16 Nov 2010
Posts: 588
Location: Kirkland, WA
|
|
| Posted: Fri Jul 24, 2015 4:26 pm |
|
|
After much research, we have discovered that is called HIFD - Hole In Foot Disease. Steel toed boots don't seem to help prevent it (based on my experience). 
mikey
_________________
mikey
-- you can't have too many gadgets or too much disk space !
old engineering saying: 1+1 = 3 for sufficiently large values of 1 or small values of 3 |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
