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

Bootloader Issue: Bootloaded program fails after address FF
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
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Fri Dec 20, 2019 2:30 am     Reply with quote

Are you sure your chip is working correctly?.

Try a similar test program, but compile it to load at address 0, and write it
with the programmer.
Ensure it does serial I/O, and tests both receive and transmit.
Have it also write at least a couple of program memory blocks, and read
these back sending the data to the UART.

I've compiled the example loader, and put it into a chip. Had to bodge
a small prototype board to connect a capacitor to VddCore, since I didn't
have a board with this. I then use the bootloader to write a program doing
FP maths, so using nearly 10K of ROM. It loads and works.
I'm running off 5v, with the Vreg enabled.

I'm wondering if you have a 'deeper' issue somewhere in your prototype
environment:
A faulty chip.
Inadequate supply regulation/smoothing.
Poor VddCore smoothing (having the right capacitor on this is vital).

Look at section 2 in the data sheet, and the guidelines. Including the
capacitor recommendations.
Chips generally are at their most 'critical' of things like supply smoothing
when writing to the flash memory.

Also, what program are you using to actually send the serial to the
bootloader?. I enabled XON/XOFF in the UART settings, and then
used ccsbootloader.exe
Cappiam



Joined: 10 Apr 2018
Posts: 17
Location: New England

View user's profile Send private message

PostPosted: Fri Dec 20, 2019 7:04 am     Reply with quote

Ttelmah wrote:
Are you sure your chip is working correctly?.

Try a similar test program, but compile it to load at address 0, and write it
with the programmer.
Ensure it does serial I/O, and tests both receive and transmit.
Have it also write at least a couple of program memory blocks, and read
these back sending the data to the UART.


One of the things I did before posting here actually. I've tried with two different boards, both have the same symptoms so I don't believe it's the chip. I mentioned earlier that the programs work if I compile and program them excluding the bootloader. I've tried with both the test program, as well as the actual code for this board(Which is about five times the length of the program that fails). One thing I do intend to try using demo board with a different PIC on it. I just need to get the parts.

Quote:
I've compiled the example loader, and put it into a chip. Had to bodge
a small prototype board to connect a capacitor to VddCore, since I didn't
have a board with this. I then use the bootloader to write a program doing
FP maths, so using nearly 10K of ROM. It loads and works.
I'm running off 5v, with the Vreg enabled.

Out of curiosity, what PIC was this test done with, the 18F45K80, or a different one?

Quote:
I'm wondering if you have a 'deeper' issue somewhere in your prototype
environment:
A faulty chip.
Inadequate supply regulation/smoothing.
Poor VddCore smoothing (having the right capacitor on this is vital).

Look at section 2 in the data sheet, and the guidelines. Including the
capacitor recommendations.
Chips generally are at their most 'critical' of things like supply smoothing
when writing to the flash memory.


This is possible, I was assigned this project after someone else had already fully designed the board and since the PIC worked correctly without the bootloader, I only paid cursory attention to the PIC connections. I'll look closer at the power connections and see if there's anything that should be changed.

EDIT: Upon examination, my board's schematic doesn't list pin 23 as Vddcore, and instead shows it as a non existent RA4 pin. I would have never noticed that the pin was incorrect on the schematic, so thank you for mentioning it. I've since attached the recommended 10uF capacitor to the board but unfortunately this did not resolve the issue.

Quote:
Also, what program are you using to actually send the serial to the
bootloader?. I enabled XON/XOFF in the UART settings, and then
used ccsbootloader.exe


I've been using the Siow.exe program, since I had an issue working with the ccsbootloader.exe. I also programmed my own slightly more flexible program in labview, though as I've mentioned before, I revert to using the provided tools when I'm trying to track down an issue.

When I ran in debugging mode, the lines the code received all looked correct(Then again it works without issue in debugging). However, this does give me an idea to test. I can use the loader.c I modified and instead of returning the address, it will return the hex buffer it receives and I'll have my program compare it with the line sent it was sent. This will at least tell me if something is lost between the two. Additionally, I can save what gets returned and compare it for differences with the hex file.

EDIT: Finished the test code, and the PIC received every single line in the hex file correctly, so I don't see communication being an issue.


Last edited by Cappiam on Fri Dec 20, 2019 10:36 am; edited 1 time in total
newguy



Joined: 24 Jun 2004
Posts: 1899

View user's profile Send private message

PostPosted: Fri Dec 20, 2019 9:29 am     Reply with quote

Cappiam wrote:
EDIT: Upon examination, my board's schematic doesn't list pin 23 as Vddcore, and instead shows it as a non existent RA4 pin. I would have never noticed that the pin was incorrect on the schematic, so thank you for mentioning it. I've since attached the recommended 10uF capacitor to the board but unfortunately this did not resolve the issue.


I learned a couple of years ago that "any old" 10uF cap might not necessarily do. Laid out a PCB with a pad for a 0603 package capacitor but the ESR in that tiny package was too high. Had to frankenstein two caps stacked on top of each other to get the ESR low enough for the PIC to stop doing funny things.
Cappiam



Joined: 10 Apr 2018
Posts: 17
Location: New England

View user's profile Send private message

PostPosted: Fri Dec 20, 2019 10:59 am     Reply with quote

newguy wrote:


I learned a couple of years ago that "any old" 10uF cap might not necessarily do. Laid out a PCB with a pad for a 0603 package capacitor but the ESR in that tiny package was too high. Had to frankenstein two caps stacked on top of each other to get the ESR low enough for the PIC to stop doing funny things.


Well that's a shame. Testing that will have to wait a couple weeks so I can get work to order a proper part to use, and holidays are going to mess with the orders going out. Either way, good information to know.
newguy



Joined: 24 Jun 2004
Posts: 1899

View user's profile Send private message

PostPosted: Fri Dec 20, 2019 11:42 am     Reply with quote

Cappiam wrote:

Well that's a shame. Testing that will have to wait a couple weeks so I can get work to order a proper part to use, and holidays are going to mess with the orders going out. Either way, good information to know.


I've been using PICs almost exclusively for nearly 20 years now. They always "just work" as long as you pay attention to the considerations in the chapter (usually) called "guidelines for getting started with ...." It's usually chapter 2 of the data sheet.

Ensure all the power and ground pins are connected. Ensure you have a decoupling cap close on all Vdd pins. Ensure that the programming header/pins are properly connected and that /MCLR has a pullup (value depends on how much EMI you're going to see), and pay attention to the crystal/clock/crystal caps and - sometimes - a series or parallel R on the crystal (depends on PIC family). And, if the processor has a Vcap pin, a suitable cap on that pin.

Any odd behaviour usually comes down to something in the list above not being properly addressed. Play with those hardware aspects first before diving into firmware which probably has nothing wrong with it.
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Fri Dec 20, 2019 1:28 pm     Reply with quote

I used a 45K80 to be sure.

I see you have a Vddcore problem. Presumably your board was actually
built for one of the chips that doesn't have this pin.
I have to mirrtor Newguy's comment about the capacitor on this pin.
I favour SMD ceramic capacitors for this. It needs a very low ESR.
Conventional electrolytics won't do.
Cappiam



Joined: 10 Apr 2018
Posts: 17
Location: New England

View user's profile Send private message

PostPosted: Mon Dec 23, 2019 6:30 am     Reply with quote

Ttelmah wrote:
I used a 45K80 to be sure.

I see you have a Vddcore problem. Presumably your board was actually
built for one of the chips that doesn't have this pin.
I have to mirrtor Newguy's comment about the capacitor on this pin.
I favour SMD ceramic capacitors for this. It needs a very low ESR.
Conventional electrolytics won't do.


I always use ceramics if they exist with the capacitance and voltage I need. In this case I picked up the project from someone else, and the schematic part was made wrong. I'm guessing they converted the schematic from the 4580, and missed the the pin change.

I'm not certain that the Vddcore is the issue since the capacitor I added in test was ceramic and it still fails but I won't be able to completely discount it until I try it with a recommended capacitor, and I won't have that until after new years.

As a note, the rest of the design specs look correct, so the Vddcore should be the only layout issue.
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Mon Dec 23, 2019 8:02 am     Reply with quote

It needs a really short track as well.

The key is that this is what actually runs the CPU core. It runs at a much
lower voltage than the I/O (typically 1.8v), and if this is wrong individual
instructions will fail for no reason at all....
Any instruction that causes a 'spike' in the load on this line is what tends
to fail.
Cappiam



Joined: 10 Apr 2018
Posts: 17
Location: New England

View user's profile Send private message

PostPosted: Thu Jan 02, 2020 2:54 pm     Reply with quote

Ttelmah wrote:
It needs a really short track as well.

The key is that this is what actually runs the CPU core. It runs at a much
lower voltage than the I/O (typically 1.8v), and if this is wrong individual
instructions will fail for no reason at all....
Any instruction that causes a 'spike' in the load on this line is what tends
to fail.


Capacitor came in, the "track" is as short as possible. It's a surface mount, and I soldered it directly to the pin, and scraped off the masking covering the ground plane to make a "pad" for the other side of the capacitor. The capacitor is one of the recommended ones from the PIC's data sheet. It didn't resolve the issue, unfortunately.

But after a break from dealing with this, I realized a huge potential difference between Debugging code, and Release code, and I'm mad at myself for not realizing it sooner. My only excuse is I got into the habit of ignoring it for several weeks while I was dealing the primary code. I didn't quickly find a way to disable it, and write protection didn't matter at the time since I hadn't started working on the bootloader portion. I'm about 95% certain this is actually the issue. When I run for debugging, a window appears saying

Quote:
The requested operation cannot continue with the following configuration bit setting(s):
Table Write Protect 00800-01FFF = Enabled
Table Write Protect 02000-02FFF = Enabled
Table Write Protect 04000-05FFF = Enabled
Table Write Protect 06000-07FFF = Enabled
Table Read Protect 00800-01FFF = Enabled
Table Read Protect 02000-02FFF = Enabled
Table Read Protect 04000-05FFF = Enabled
Table Read Protect 06000-07FFF = Enabled


Then it gives me the option to change it for this session, or cancel it. I want to program the PIC for release with these configurations disabled, but I can't find any fuses for Table Read protections(or Program memory write protections), though I do find ones for code protect, and boot block protect. Am I just going down a rabbit hole, or if not, any idea where or how I can change those registers to disabled in my primary code?

I have tried using write_configuration_memory. However, the WRT registers appear to be protected since when I read the registers back, they remain unchanged. I am able to write to other configuration registers.
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Fri Jan 03, 2020 1:34 am     Reply with quote

Explicitly set the protection fuses off:
Code:

#FUSES NOWDT           
#FUSES NOPROTECT
#fuses 6=0xE00F
Cappiam



Joined: 10 Apr 2018
Posts: 17
Location: New England

View user's profile Send private message

PostPosted: Fri Jan 03, 2020 6:51 am     Reply with quote

Ttelmah wrote:
Explicitly set the protection fuses off:
Code:

#FUSES NOWDT           
#FUSES NOPROTECT
#fuses 6=0xE00F


The #fuses 6=0xE00F was the information I needed. I didn't know how to set the registers manually in CCS C. Regardless, it doesn't fully resolve the issue. I also need to include #fuses 7=0x400F to enable the table read. Now everything appears to work correctly. I'm still a bit upset with myself that I didn't recognize the issue sooner.
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Fri Jan 03, 2020 8:25 am     Reply with quote

As a question, are you changing the BBSIZE setting in the fuses?.
The reason I ask, is the default boot block size should give this issue
at 0x7FF, not at 0xFFF. This was why I didn't consider this as the likely
cause of the issue.
Cappiam



Joined: 10 Apr 2018
Posts: 17
Location: New England

View user's profile Send private message

PostPosted: Fri Jan 03, 2020 10:03 am     Reply with quote

Ttelmah wrote:
As a question, are you changing the BBSIZE setting in the fuses?.
The reason I ask, is the default boot block size should give this issue
at 0x7FF, not at 0xFFF. This was why I didn't consider this as the likely
cause of the issue.


Until I realized it the code defaulted to write protected, I used very few #fuse settings, none of which should have changed the boot block size settings, and for the majority of the tests, I didn't add fuses to the base bootloader code, just the #include for the chip, and the change to the UART pins. Now I've added several to explicitly turn all of the protections off, though other than WRT and EBTR (The two missing from fuse options), the protections appear to already be off by default. I also noticed when I used read_configuration_memory( ) that the boot block size was set to 2k rather than 1k. As far as I can tell, that's the default value, since it remains that way even when all fuses are removed.
temtronic



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

View user's profile Send private message

PostPosted: Fri Jan 03, 2020 12:34 pm     Reply with quote

You may ( should ?) add every #FUSE your PIC uses, with a comment at the end. I learned the hard way that someone else's 'default' were NOT what I considered MY default values...
I know, modern PICs have lots of fuses, but you can type them all in once, save as a file, then #include my_fuses_filename....
Having a known set of fuses as a template for future projects will speed up development and maybe save a few hairs !
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Fri Jan 03, 2020 2:36 pm     Reply with quote

On most modern PIC's, the default for the fuses is their erased state.
However this one seems to be an exception to this. So the 'NOPROTECT'
setting is actually turning off the low four bits of the protection register,
which results in protection being enabled. Worth probably pointing this
out to CCS.
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