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

the bootloader looks ok but the code doesn't run
Goto page Previous  1, 2
 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
jeremiah



Joined: 20 Jul 2010
Posts: 1190

View user's profile Send private message

PostPosted: Wed Sep 02, 2020 1:53 pm     Reply with quote

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: 1190

View user's profile Send private message

PostPosted: Wed Sep 02, 2020 2:09 pm     Reply with quote

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: 23

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

PostPosted: Thu Sep 03, 2020 8:25 am     Reply with quote

Quote:
So CCS reads the bootloader hex file parsing the addresses as 2x their actual value

i don't understand Embarassed

Quote:
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

They are (almost) the same. The file I read is (from 0 to 0xfae) the bootloader and (from 0x1000 to 0x10A2) the blink firmware.
I notice one thing: the bootloader does not end at 0xFAE but, from the address 0x1000 to 0x1004 it writes: "1000 EF0E F000 0012". Maybe they are the fuses?
Ttelmah



Joined: 11 Mar 2010
Posts: 16408

View user's profile Send private message

PostPosted: Thu Sep 03, 2020 8:37 am     Reply with quote

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: 1190

View user's profile Send private message

PostPosted: Thu Sep 03, 2020 7:07 pm     Reply with quote

ciccioc74 wrote:
Quote:
So CCS reads the bootloader hex file parsing the addresses as 2x their actual value

i don't understand Embarassed


There are multiple different HEX file formats and you can tell CCS to compile code into many of them in your project settings. When I opened up both of the hex files you posted in CCS (File->Open->Any File and select the hex file), the thing I noticed was that CCS was reading the bootloader hex file with addresses that were half of what you see if you open the hex file in say Notepad. On the flip side, CCS opened the application hex file using the same addresses as you see when you view it in Notepad. This suggests that the two different HEX files were created in two different file formats. My *guess* is that your bootloader is designed to read a specific file format and the default one your copy of CCS is doing is a different file format, so code is being put into the wrong place relative to where the bootloader expects it to be.

ciccioc74 wrote:

Quote:
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

They are (almost) the same. The file I read is (from 0 to 0xfae) the bootloader and (from 0x1000 to 0x10A2) the blink firmware.
I notice one thing: the bootloader does not end at 0xFAE but, from the address 0x1000 to 0x1004 it writes: "1000 EF0E F000 0012". Maybe they are the fuses?

That would not be the FUSES. Your fuses are at 0x300000-0x30000D:
Code:

:020000040030CA   <== Sets the upper address word to 0x0030
:0100000021DE     <== Places fuse data at 0x00300000
:0100010008F6     <== Places fuse data at 0x00300001
:010002001FDE
:010003003EBE
:0100050011E9
:010006008178
:010008000FE8
:01000900C036
:01000A000FE6
:01000B00E014
:01000C000FE4
:01000D0040B2


If the combination of the two files does not match the one you read off of your chip after programming the application via the bootloader, then that is a strong hint your bootloader isn't loading the application correctly. That might be because of the application hex file not being in the expected HEX file format or it might be something wrong with the bootloader.

EDIT: It looks like CCS currently only exports 8bit hex, 16bit hex, and binary files for that chip. I think the bootloader is in 32bit hex format but I am not 100% sure.
Ttelmah



Joined: 11 Mar 2010
Posts: 16408

View user's profile Send private message

PostPosted: Fri Sep 04, 2020 12:34 am     Reply with quote

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: 21227

View user's profile Send private message

PostPosted: Fri Sep 04, 2020 1:13 am     Reply with quote

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: 16408

View user's profile Send private message

PostPosted: Fri Sep 04, 2020 1:31 am     Reply with quote

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: 16408

View user's profile Send private message

PostPosted: Fri Sep 04, 2020 7:17 am     Reply with quote

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: 23

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

PostPosted: Mon Sep 07, 2020 10:42 am     Reply with quote

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



Joined: 23 Mar 2010
Posts: 23

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

SOLVED
PostPosted: Wed Sep 23, 2020 1:29 am     Reply with quote

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 :
Code:

//how big is the bootloader?
//the bootloader will reside from address 0x0000 to this location.  the
//application will then sit at this location+1 to the end of program memory.
#define LOADER_SIZE                 (0xFFF)
#define LOADER_START                (0)
#define LOADER_END                  (LOADER_SIZE)
#define APPLICATION_START           (LOADER_SIZE+1)
#define APPLICATION_END             (getenv("PROGRAM_MEMORY")-1)
#define APPLICATION_ISR             (APPLICATION_START+8)

//#define _bootloader

#ifndef _bootloader
    //in the application, this moves the reset and isr vector out of the bootload
    //space.  it then reserves the loader space from being used by the application.
    #BUILD(RESET=APPLICATION_START, INTERRUPT=APPLICATION_ISR)
    #org 0, LOADER_END {}


   #fuses NONE
   #use delay(clock=24000000)

#else

in my source is essential.
The line: 020000040000FA is not essential.
Now I'm working on the merge (bootloader+my fw) and a source in VB6 (or visual C)to modify as i want.
Thanks everyone for your kind help.
temtronic



Joined: 01 Jul 2010
Posts: 7674
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Wed Sep 23, 2020 5:30 am     Reply with quote

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: 16408

View user's profile Send private message

PostPosted: Wed Sep 23, 2020 5:52 am     Reply with quote

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.
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 Previous  1, 2
Page 2 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