| View previous topic :: View next topic |
| Author |
Message |
SeeCwriter
Joined: 18 Nov 2013
Posts: 160
|
| Using Bootloader |
 Posted: Mon Jul 15, 2019 10:06 am |
 |
|
Using the bootloader and test program listed below, the test program doesn't run. I'm using v5.085 IDE with a PIC18F67K22. For a terminal I'm using Tera-Term. Is there something I missed?
Loader:
| Code: |
#include <18F67K22.h>
#device ADC=16
#fuses PUT, HSH, BORV30, NOWDT
#define BOOTLOADER_STREAM COM1
#use delay(clock=64000000,internal=16000000)
#use rs232(baud=38400,parity=N,xmit=PIN_C6,rcv=PIN_C7,bits=8,stream=BOOTLOADER_STREAM)
#define _bootloader
#include <bootloader.h>
#include <loader.c>
#define PUSH_BUTTON PIN_B4
#define PROGRAMMING_MODE() (!input(PUSH_BUTTON))
#if defined(__PCM__)
#org LOADER_END+1,LOADER_END+2
#elif defined(__PCH__)
#org LOADER_END+2,LOADER_END+4
#else
#error Compiler Not Supported!
#endif
void application(void) {
while(TRUE);
}
void main()
{
setup_oscillator( OSC_16MHZ | OSC_PLL_ON ); // Required when using Internal osc. with 4X PLL enabled.
// Enter Bootloader if Pin B4 is low after a RESET
if( PROGRAMMING_MODE() )
{
printf("\r\nPIC Bootloader v1.0\r\n");
// Let the user know it is ready to accept a download.
printf("Waiting for download...");
load_program();
}
application();
}
#INT_GLOBAL
void isr( void )
{
jump_to_isr( LOADER_END + 9 );
}
|
Test Program:
| Code: |
#include <18F67K22.h>
#device ADC=16
#use delay(clock=64000000,internal=16000000)
#include <bootloader.h>
void main(void)
{
int x=0;
setup_oscillator( OSC_16MHZ | OSC_PLL_ON );
while(TRUE)
{
delay_ms(500);
if ( x ) output_low( PIN_C2 );
else output_high( PIN_C2 );
x = !x;
}
}
|
Edit:
I put some preprocessor commands in the loader program to view the values of various defines, and they all look good.
#warning Loader end: LOADER_END
#warning Loader size: LOADER_SIZE
#warning Loader addr: LOADER_ADDR
#warning Program mem: getenv("PROGRAM_MEMORY")
#warning Flash erase size: getenv("FLASH_ERASE_SIZE")
#warning Flash write size: getenv("FLASH_WRITE_SIZE")
#warning Bits per Instr: getenv("BITS_PER_INSTRUCTION")
#warning Count = (getenv("PROGRAM_MEMORY") % getenv("FLASH_ERASE_SIZE"))
#if getenv("PROGRAM_MEMORY") <= 0x10000
#warning Program memory less than 65536
#endif
Output of #warnings:
Loader end: 0x4FF
Loader size: 0x4FF
Loader addr: 0x4FF-0x4FF
Program mem: 131072
Flash erase size: 128
Flash write size: 128
Bits per Instr: 16
Count = (131072 % 128)
I also examined the listings of both the loader and the test program being uploaded. The function "application" is located at address 0x500 as it should be. And the test program is located at address 0x500 as I expected. |
|
 |
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Mon Jul 15, 2019 6:35 pm |
|
|
| Later tonight, I can test this with an 18F46K22. |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Tue Jul 16, 2019 12:16 am |
|
|
I got it to the point where I'm getting the same problem as you.
It goes into bootloader mode and waits for me to send a hex file.
I use TeraTerm to send it, and it sends the hex file, apparently OK.
But it doesn't run.
| Quote: |
I also examined the listings of both the loader and the test program
being uploaded. The function "application" is located at address 0x500
as it should be. And the test program is located at address 0x500 as I
expected.
|
Have you looked at the Program Memory after using the programmer
to read the flash (after downloading the application hex file) ?
I did that, and I see this:
0500 BRA 0500
0502 RETURN 0
I don't see the application program. I don't think it's being written to flash
by the bootloader. Or I'm doing it wrong. I'm testing with CCS vs. 5.085.
My next step is to try an earlier version of CCS. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19549
|
|
| Posted: Tue Jul 16, 2019 2:58 am |
|
|
I have to ask why the code is fiddling around with the clock rate?.
The way to set to use the internal with the PLL, is simply:
#use delay(internal=64MHz)
and get rid of the setup_oscillator line.
The setup_oscillator, is _not_ 'required'....
Think the thing to do is verify that a program memory write is working.
Will go and have a play and see if it does.
What you are seeing PCM_Programmer, suggests it isn't, since this looks
exactly the code that would be expected for the dummy while loop
in the bootloader 'application'.... |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19549
|
|
| Posted: Tue Jul 16, 2019 3:52 am |
|
|
Have just confirmed the EEPROM write code works OK with this compiler
version and chip. Merrily wrote a block to 0x500, and then read it back with
the programmer and all is fine.
Looking at the bootloader, there is a potential issue. The default value
for BUFFER_LEN_LOD, is 64. This is OK for a PIC18Fx5K22 or x6K22, but
needs to be set to 128 for a x7K22. So:
| Code: |
#define _bootloader
#define BUFFER_LEN_LOD 128
#include <bootloader.h>
#include <loader.c>
|
This may be the problem. |
|
|
SeeCwriter
Joined: 18 Nov 2013
Posts: 160
|
|
| Posted: Tue Jul 16, 2019 8:06 am |
|
|
Changing BUFFER_LEN_LOD to 128 made no difference.
At one time, the only way to enable 4X PPL mode was to use setup_oscillator. Perhaps that's changed now, I haven't checked.
Edit: After uploading the application with the bootloader I used the programmer to read the contents of the program memory. At address 0500, there is a GOTO statement (opcode EF), not a BRA. And there is no code after. So it appears the application is not being written to memory. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19549
|
|
| Posted: Tue Jul 16, 2019 12:32 pm |
|
|
Which is what PCM_Programmer reported.
I'm not in a position to get serial running on one of these at the moment,
hence can't test what is going on.
However as I said I did a basic test of writing a block of 128bytes at
address 0x500, and then read this and tested the checksum, flashed
an LED if it is what should be. It is right, so the program memory write
function is working. So the question is why it is not being called?. |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Tue Jul 16, 2019 1:24 pm |
|
|
What I plan to do, later this evening, is to try an earlier version(s) of CCS
and find if it works. Also, I will try a different family of PICs with the
current version, and if it works, then look at how it's different for the
K22 series. |
|
|
SeeCwriter
Joined: 18 Nov 2013
Posts: 160
|
|
| Posted: Mon Jul 22, 2019 10:28 am |
|
|
| Any success at finding the problem? |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Mon Jul 22, 2019 10:43 am |
|
|
I am still working on it. I believe I found a problem with my computer,
just last night. I had "assumed" my computer was functional, so I spent
a large amount of time testing different boards, PICs, compiler versions,
re-installing TeraTerm, etc. Now I think it's actually the hardware serial
port. I'm going to fix it now, or switch computers. I will get back to you
soon on the bootloader problem. |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Tue Jul 23, 2019 5:29 am |
|
|
I finally got it to work with an 18F46K22 (DIP-40), CCS PCH vs. 5.085,
TeraTerm vs. 4.78, MPLAB vs. 8.92, and a PicKit-3.
Here are the changes I made to Ex_bootloader.c:
| Code: | #include <18F46K22.h>
#use delay(internal=16MHz )
//#use rs232(icd)
#use rs232(baud=9600, xmit=PIN_C6, rcv=PIN_C7)
#define PUSH_BUTTON PIN_A4 |
My board has a button on Pin A4 instead of B5. I also didn't want to use
the PLL during initial trouble-shooting. I haven't tested it yet.
Also, I wanted to use a low (9600) serial speed for initial testing.
Also in Ex_bootloader.c, I had to change the indicated line below
to get it to compile without giving an #org error:
| Code: |
#include <bootloader.h>
#include <loader.c>
#org LOADER_END+1,LOADER_END+4 // *** Changed to 4, was 2 ***
void application(void) {
while(TRUE);
}
|
Then in the application program, Ex_bootload.c, it has the same header
changes as for Ex_bootloader.c:
| Code: | #include <18F46K22.h>
#use delay(internal=16MHz )
//#use rs232(icd)
#use rs232(baud=9600, xmit=PIN_C6, rcv=PIN_C7)
|
In Windows, I enabled Xon/Xoff for the COM1 serial port. This is a real
COM1 port and not a USB-to-COMport adapter. I didn't test it with an
adapter. Also, I disabled all FIFO buffers for the COM1 port. It says
to do this somewhere in the CCS bootloader documentation.
In TeraTerm, I set it for 9600,N,8,1 with Xon/Xoff enabled.
At first, it didn't work. I made a lot of stupid errors. Everything has to
be exactly right. Eventually I got the procedure down correctly.
It still didn't work. Then I decide to try SIOW. It failed with a timeout
error. We've seen that before on the forum. But it gave me an idea.
I went back to TermTerm and added a 10ms per character delay, and
a 100ms per line delay. Then it worked. It displays incrementing numbers
in the TeraTerm window.
If I use MPLAB vs. 8.92 to read the PIC and look at program memory,
I can see code in the range 0x500 to 0x664. This is the application
program, Ex_bootload.c, successfully written to flash during the
bootloading process. |
|
|
SeeCwriter
Joined: 18 Nov 2013
Posts: 160
|
|
| Posted: Tue Jul 23, 2019 9:49 am |
|
|
| So, the only change needed to get it to work is to add the delays to TeraTerm? |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Tue Jul 23, 2019 11:16 am |
|
|
No, I also had to do this:
| Quote: |
Also in Ex_bootloader.c, I had to change the indicated line below
to get it to compile without giving an #org error:
#include <bootloader.h>
#include <loader.c>
#org LOADER_END+1, LOADER_END+4 // *** Changed to 4, was 2 ***
void application(void) {
while(TRUE);
}
|
|
|
|
SeeCwriter
Joined: 18 Nov 2013
Posts: 160
|
|
| Posted: Tue Jul 23, 2019 12:32 pm |
|
|
| If you look at the bootloader in my original post, it has #org set the same. I don't see any difference between your code and what I have, other than the serial baud rate. And I wouldn't think the baud rate would be an issue. |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Tue Jul 23, 2019 12:34 pm |
|
|
| OK, then I guess it is down to the delays added in TeraTerm. |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
