 |
 |
| View previous topic :: View next topic |
| Author |
Message |
BLL
Joined: 11 Nov 2006
Posts: 181
Location: Birmingham, UK
|
| Bootloading 18LF2620 |
 Posted: Sat Jun 25, 2016 8:21 am |
 |
|
Hi, I am trying to use bootloading for the first time and am getting nowhere!
The PIC is a 18LF2620 and I have compiled and loaded ex_bootloader.c, having set the pin to check to A5.
I have then tried to transfer my program's .hex file, having grounded A5.
With teraterm, it uploaded the file to the PIC without errors but then on powering up my board with pin A5 now high, my program does not start.
I then tried using siow.exe with correct port settings and it reported port timeout and did nothing.
I tried ccsinfo and it said it couldn't find the programmer!
Since it uploaded with teraterm but didn't start the program, is the code in bootloader.c correct for the 18LF2620?
| Code: |
#if defined(__PCM__)
#org LOADER_END+1,LOADER_END+10
#elif defined(__PCH__)
#org LOADER_END+2,LOADER_END+20
#endif
//-----------------------------------------------------------------------------
void application(void)
{
while(TRUE);
}
//-----------------------------------------------------------------------------
#if defined(__PCH__)
#org 0x40,0x7F
#else
#org 0x20,0x3F
#endif
//-----------------------------------------------------------------------------
void main(void)
{
if(!input(PIN_A5)) //was B5
{
load_program();
}
application();
}
//-----------------------------------------------------------------------------
#ORG default
//-----------------------------------------------------------------------------
#int_global
void isr(void)
{
jump_to_isr(LOADER_END+5*(getenv("BITS_PER_INSTRUCTION")/8));
} |
I just have a pl2303 usb/serial device connected to the PIC's serial port on C6 and C7, which appears as COM12 in Windows. Baudrate is set to 9600.
Any help much appreciated.
Brian |
|
 |
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Sat Jun 25, 2016 1:55 pm |
|
|
Vs. 5.059 doesn't have this in any ex_bootloader.c or ex_bootload.c file.
| Quote: | #if defined(__PCH__)
#org 0x40,0x7F
#else
#org 0x20,0x3F
#endif |
I think it's from some older compiler version.
1. Post your compiler version.
2. Post your oscillator type and frequency.
3. Post the Vdd voltage of your 18LF2620. |
|
|
BLL
Joined: 11 Nov 2006
Posts: 181
Location: Birmingham, UK
|
| Bootload 18LF2620 |
| Posted: Sat Jun 25, 2016 3:14 pm |
|
|
Hi, My compiler is 4.110.
The Pic is on 5V, 10MHz xtal oscillator |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9245
Location: Greensville,Ontario
|
|
| Posted: Sat Jun 25, 2016 5:42 pm |
|
|
couple of comments...
going back a few steps...
1) Does the PIC actually work? Can you code/compile/run a 1Hz LED program to verify 'it's alive and well'?
I'd expect a PIC with JUST a bootloader installed to say flash an LED at 1 Hz just to PROVE the bootloader code itself is actually in there!
2) If you only have one compiler, get rid of the if defined ...compiler, set this else other compiler set these........
It can be confusing and really awkward to understand what and why the 'if' is for. I find it better to 'hard code', then again I also put comments on every line too !
Jay |
|
|
BLL
Joined: 11 Nov 2006
Posts: 181
Location: Birmingham, UK
|
| Bootload 18LF2620 |
| Posted: Sun Jun 26, 2016 1:51 am |
|
|
Hi, Thanks for the reply.
The PIC works - I have programmed it with my programmer with my large application and it works fine.
I can upload the .hex file with Teraterm, which suggests that the uploading is working? Since my program then isn't found, it seems to me to suggest that it is not jumping to the program's start location?
However, there is the further complication that siow won't upload the code!
I will tidy up the bootloader code, but I am not confident it will make a difference!
Brian |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19546
|
|
| Posted: Sun Jun 26, 2016 3:48 am |
|
|
What is making pin A5 go high?.
You do realise you need a resistor to do this?. |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Sun Jun 26, 2016 7:06 am |
|
|
I tried running this in hardware with vs. 4.110 and I think there must be
a bug in loader.c.
I programmed the HEX file for ex_bootloader.c in the 18F2620, and then
jumpered pin A5 to ground, and pressed the reset button. Then I used
Teraterm to "Send" the HEX file for ex_bootload.c to the PIC. I edited
both files to use only a 10MHz crystal with no PLL for now. I edited
Ex_Bootloader.c to use pin A5, the same as BLL does. Etc. I also got rid
of the printf statements in Ex_Bootload.c and substituted a few putc()
statements for simplicity.
After downloading the application HEX file (Ex_bootload.c), nothing
happens in TeraTerm. I used MPLAB vs. 8.92 to read the flash memory
in the PIC, so I could see what was actually downloaded to it.
Here's the memory starting at address 0x500, which is where the
application program is written by loader.c. Notice that it has chunks
of memory (8 instructions) that are full of NOP's. I think there is
something wrong with Loader.c for the 18F2620 for vs. 4.110.
| Code: | Line Address Opcode Disassembly
641 0500 EF88 GOTO 0x510
642 0502 F002 NOP
643 0504 FFFF NOP
644 0506 FFFF NOP
645 0508 FFFF NOP
646 050A FFFF NOP
647 050C FFFF NOP
648 050E FFFF NOP
649 0510 6AF8 CLRF 0xff8, ACCESS
650 0512 9ED0 BCF 0xfd0, 0x7, ACCESS
651 0514 6AEA CLRF 0xfea, ACCESS
652 0516 6AE9 CLRF 0xfe9, ACCESS
653 0518 96B8 BCF 0xfb8, 0x3, ACCESS
654 051A 0E40 MOVLW 0x40
655 051C 6EAF MOVWF 0xfaf, ACCESS
656 051E 0EA6 MOVLW 0xa6
657 0520 FFFF NOP
658 0522 FFFF NOP
659 0524 FFFF NOP
660 0526 FFFF NOP
661 0528 FFFF NOP
662 052A FFFF NOP
663 052C FFFF NOP
664 052E FFFF NOP
665 0530 6EB4 MOVWF 0xfb4, ACCESS
666 0532 0E41 MOVLW 0x41
667 0534 DFE9 RCALL 0x508
668 0536 0E42 MOVLW 0x42
669 0538 DFE7 RCALL 0x508
670 053A 0E43 MOVLW 0x43
671 053C DFE5 RCALL 0x508
672 053E 0E58 MOVLW 0x58
673 0540 FFFF NOP
674 0542 FFFF NOP
675 0544 FFFF NOP
676 0546 FFFF NOP
677 0548 FFFF NOP
678 054A FFFF NOP
679 054C FFFF NOP
680 054E FFFF NOP
681 0550 FFFF NOP
|
Here is the Ex_bootload.c code that was compiled. This is what should
have been written to address 0x500:
| Code: |
Line Address Opcode Disassembly
641 0500 EF88 GOTO 0x510
642 0502 F002 NOP
643 0504 FFFF NOP
644 0506 FFFF NOP
645 0508 A89E BTFSS 0xf9e, 0x4, ACCESS // TXIF == 1 ?
646 050A D7FE BRA 0x508 // Stay in loop until it is.
647 050C 6EAD MOVWF 0xfad, ACCESS // write to TXREG
648 050E 0C00 RETLW 0
649 0510 6AF8 CLRF 0xff8, ACCESS
650 0512 9ED0 BCF 0xfd0, 0x7, ACCESS
651 0514 6AEA CLRF 0xfea, ACCESS
652 0516 6AE9 CLRF 0xfe9, ACCESS
653 0518 96B8 BCF 0xfb8, 0x3, ACCESS
654 051A 0E40 MOVLW 0x40
655 051C 6EAF MOVWF 0xfaf, ACCESS
656 051E 0EA6 MOVLW 0xa6
657 0520 6EAC MOVWF 0xfac, ACCESS
658 0522 0E90 MOVLW 0x90
659 0524 6EAB MOVWF 0xfab, ACCESS
660 0526 50C1 MOVF 0xfc1, W, ACCESS
661 0528 0BC0 ANDLW 0xc0
662 052A 090F IORLW 0xf
663 052C 6EC1 MOVWF 0xfc1, ACCESS
664 052E 0E07 MOVLW 0x7
665 0530 6EB4 MOVWF 0xfb4, ACCESS
666 0532 0E41 MOVLW 0x41 // Putc('A');
667 0534 DFE9 RCALL 0x508
668 0536 0E42 MOVLW 0x42 // Putc('B');
669 0538 DFE7 RCALL 0x508
670 053A 0E43 MOVLW 0x43 // Putc('C');
671 053C DFE5 RCALL 0x508
672 053E 0E58 MOVLW 0x58 // Putc('X');
673 0540 DFE3 RCALL 0x508
674 0542 D7FD BRA 0x53e
675 0544 0003 SLEEP
676 0546 FFFF NOP
677 0548 FFFF NOP
678 054A FFFF NOP
679 054C FFFF NOP
680 054E FFFF NOP
681 0550 FFFF NOP
|
|
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19546
|
|
| Posted: Sun Jun 26, 2016 8:25 am |
|
|
It could even be a bug with the 'write_program_memory' function.
4.110, was at a time where there were some odd bugs. I didn't bother to keep it, since I found that programs which were working around the 4.100 area, stopped working with some of the versions at this time....
I have a 'gap' in stored versions from 4.104 to 4.112, where I found too many things were not working to bother to keep them. |
|
|
BLL
Joined: 11 Nov 2006
Posts: 181
Location: Birmingham, UK
|
| Bootload 18LF2620 |
| Posted: Sun Jun 26, 2016 3:03 pm |
|
|
Hi all,
Yes, I have a 10K resistor from A5 to VCC and a switch to ground.
I think there is definitely a problem with CCS's bootload programs.
siow normally talks to my PIC fine - I send a character and it returns a comma delimited string.
However, when the bootload prog is running in the PIC and you try and upload the hex file with siow, it says it can't find the port! I haven't looked closely at their code but I guess that their PIC code is grabbing the port, so siow can't access it.
4.110 is the latest version I have, otherwise it's 3.249!
Brian |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19546
|
|
| Posted: Mon Jun 27, 2016 12:57 am |
|
|
3.249, may well be better!....
V4, didn't work till about 4.070, then had 'bursts' of two or three working versions, followed by ones with bugs.
However, not sure that 3.249, would support the LF2620.
That being said, I don't think 4.110 does either. Proper support for the LF version wasn't fully added till about 2012, at around 4.13x.
As you will see, PCM_programmer was testing for the F2620, not the LF2620. |
|
|
BLL
Joined: 11 Nov 2006
Posts: 181
Location: Birmingham, UK
|
| Bootloading 18LF2620 |
| Posted: Mon Jun 27, 2016 9:20 am |
|
|
That's interesting. I thought that the differences between the F and LF versions were the ability of the LF to work down to 3.3V and reduced power consumption, so I presumed that it didn't matter if one selected the F device in code, but used it on an LF device.
Brian |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Mon Jun 27, 2016 12:14 pm |
|
|
I tested vs. 4.141 and it worked OK. Vs. 4.141 was/is a pretty solid
version. If you want to use vs. 4, why not ask CCS support if they have
a low cost upgrade deal, where they upgrade you to vs. 4.141 for some
nominal charge ? Maybe they would do it.
If not, we can continue looking at the reason why 4.110 fails, and maybe
offer a work-around. But if you could skip all that by getting vs. 4.141,
it would be better. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19546
|
| Re: Bootloading 18LF2620 |
| Posted: Mon Jun 27, 2016 1:18 pm |
|
|
| BLL wrote: | That's interesting. I thought that the differences between the F and LF versions were the ability of the LF to work down to 3.3V and reduced power consumption, so I presumed that it didn't matter if one selected the F device in code, but used it on an LF device.
Brian |
On some PIC's, the version numbers and chip ID's are different. I don't think this is the case for this one. However there is one important 'feature', which is an answer to a question PCM_programmer has already asked. What is your Vdd?. The chips can't self erase below 3v, so you can't use a bootloader below this. |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Mon Jun 27, 2016 2:14 pm |
|
|
He answered that in post #3. It's 5v. Once I saw that, I knew I could
easily test it with my 18F2620 and a PicDem-Plus board. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19546
|
|
| Posted: Mon Jun 27, 2016 2:31 pm |
|
|
Good. Missed that reply. 
As you say, makes it easy then to test.
I suspect it is a memory programming problem with his version. Have tried 3.249, and it programs OK.
There is also another issue. He talks about SIOW, not 'seeing' the port, when it is connected to the programmer. The bootloader does nothing to the port. It sounds rather as if he has another program open that is then interfering (only one device can actually talk to a standard comm port at any time).
Also he does need to have software handshaking enabled on the port, for bootloading. |
|
|
|
|
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
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
