the bootloader looks ok but the code doesn't run

jeremiah · Joined: 20 Jul 2010 Posts: 1353

ok, so I don't have as much PIC18 experience, but it seems odd that the bootloader is addressing 180000-180006. I'm assuming that is the FUSES, but I am used to how they do it on the PIC24 and they put the fuses as the last words in user program memory. Maybe someone with more PIC18 experience can comment on how the fuses are handled.

The bootloader is definitely smaller than 0x1000, so you are safe there.

Next step. Can you program a board with the bootloader, then load the the application via USB and then when complete turn it off, start it up with the programmer and read off the HEX file from the chip directly? At that point we can compare the combined file created by the bootloader to the two individual hex files to make sure they match up. That'll eliminate the possibility that the bootloader is incorrectly storing the application to memory.

jeremiah · Joined: 20 Jul 2010 Posts: 1353

So CCS reads the bootloader hex file parsing the addresses as 2x their actual value (meaning CCS displays the addresses as 1/2 the number in the raw hex file), which is different from how it reads the application hex file.

Does this imply that the two hex files are different hex formats? That might cause a problem.

ciccioc74 · Joined: 23 Mar 2010 Posts: 30

Ttelmah · Joined: 11 Mar 2010 Posts: 19537

Who's bootloader is it?.
I have a 'niggling memory', of somebody posting here before with an issue
with a small USB bootloader. It was something to do with the hex format
not being handled correctly.
Jeremiah's suggestion is the way to go. This will show if the file is being
loaded correctly.

jeremiah · Joined: 20 Jul 2010 Posts: 1353

Ttelmah · Joined: 11 Mar 2010 Posts: 19537

Again, tell us who's bootloader this is.
Hopefully the 'paperwork' for this will tell us what format it actually
wants.
The bootloader code, includes the 'dummy' application at 0x1000. This is
overwritten when the real application loads. This is what you are seeing
there.
I'm firmly of the belief, that the problem you have is that the
bootloader you are trying to use is not written to load the Hex format being
generated by default by the compiler. CCS can generate a couple of
formats, and there are tools out there (like HexIt), which can load one
format and output in another. However we need to know what bootloader
this actually is, to have any hope of working out what format it requires....

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

In this thread, he says he's using Microchip HID bootloader vs. 2.3
He says it was written in C18 but he modified it for CCS.
http://www.ccsinfo.com/forum/viewtopic.php?t=57489
He has posted at least some of the source code for that bootloader in that thread.

Ttelmah · Joined: 11 Mar 2010 Posts: 19537

OK. Well the Microchip HID bootloader accepts standard Hex as generated
by CCS. So it should work.

It really would be informative to see the actual dump read from the
programmer, of what has been written into the application area after
the bootloader has been used. If this is right, then it should work.

He might well have an issue with more complex programs. Without looking
at the MicroChip code, I don't know if this bootloader does handle the
ISR re-vectoring, in a CCS compatible way, but this will only apply when
he uses code that has an ISR.

So, please post what is in the memory at 0x1000 after the bootloader has
attempted to load the program.

Ttelmah · Joined: 11 Mar 2010 Posts: 19537

I knew I had seen something about using the HID bootloader with CCS.
You need to add the line:

:020000040000FA

To the start of your application hex file.

What happens is that CCS don't include this, since they assume all
programmers will start with the upper base address set to zero.
The HID bootloader though does not clear this address at the start, and
requires it to be initialised.
Without this the code can and will locate incorrectly.

The line is there in the bootloader, but not in the application.

It is covered here:

<http://www.picprojects.net/usbbootloader/>

ciccioc74 · Joined: 23 Mar 2010 Posts: 30

Thanks for your kind help. I do some tests and I refer to you.

ciccioc74 · Joined: 23 Mar 2010 Posts: 30

Solved.
The problems were many. Meanwhile, the latest version of MLA was giving problems, I used the 2013 version (http://ww1.microchip.com/downloads/en/softwarelibrary/mla_v2013_12_20_windows_installer.exe) here I used the version for pic18f45k50.
I used pickit 3 to download the fw but the PK2DeviceFile.dat file downloaded to use the 18f45k50 gave a sneaky problem: it seemed to download the fw but did not write to all memory. My fw worked but with the bootloader it didn't.
Another problem was that I connected the button to the RE3 pin also used by MCLR, so we need to disable the use of the MCLR pin in FUSES.
Another problem is quartz. Since my board uses serial communication (rs232 @ 9600) I thought the internal oscillator is not reliable. The 8MHz crystal that I had initially mounted is not compatible with USB speeds. I opted for a 16MHz.
The code :

temtronic · Posted: Wed Sep 23, 2020 5:30 am

hmm... I got curious about clock and USB...
from your original post...32MHz USB

So I downloaded the datasheet. That PIC supports both low and full speed USB but requires a 6 or 48 MHz clock for USB operations, so there is no 32 MHz USB.
They do allow the internal RC clock to be used for USB though, so it 'should' have worked at 6 or 48.

Jay

Ttelmah · Joined: 11 Mar 2010 Posts: 19537

No.
To use the internal oscillator for full speed USB, you have to have ACT
enabled. It could have run at 24MHz with the USB programmed for low speed,
but the USB code is setup for high speed operation.