 |
 |
| View previous topic :: View next topic |
| Author |
Message |
m4rcdbk
Joined: 29 Aug 2016
Posts: 10
Location: Michigan, USA
|
| PIC24F bootload strangeness |
 Posted: Mon Aug 29, 2016 3:34 pm |
 |
|
Hi Group,
I've been following around [lurking more or less] trying to figure out a bootload method for my PIC24FJ128GA010. Most of what I have found, combined with the microchip design documents is very straightforward -- thank you to all who have put forth great suggestions and great workarounds.
So, the situation is this:
I have a PCB that has said PIC on board, this PIC has external EEPROM addressed over SPI. While this isn't an issue, I'm only pointing it out as it may be a viable option (Can something bootload from external EEPROM?).
The datasheet says that this PIC can only be programmed on a power-on reset, among a few other things that I haven't run across as issues.
The firmware we have today doesn't allow bootloading, so I am attempting to incorporate a bootloader into the current PIC. The idea I have is I will take the current PIC firmware, go down 1 erase Page, write the configuration bits that indicate we have additional boot firmware, and if detected will jump to that code and begin it's execution. Otherwise, if one is not detected it has the base load integrated into it already and can operate as "current". Our product doesn't have a way to plug into it remotely hence this desire. That, and it's simply too time consuming to execute a firmware update over 100+ modules in the wild.
The issue I have is that running the code, I erase 1 page after the end of our current code, and then place a config magic number start. The execution does not stop for some reason, and runs right into the ROM that has the magic number. I've checked via the ROM in the debugger as well as address space provided by the lst file that we're not putting the magic number into the actual command space; which we're not. Has any one heard of this, or know of any potential issues where this would occur? Is there something I need to set the ROM to that way it knows it's the "end of execution" zone?
Let me know if you have questions, thoughts or if you need any code provided. |
|
 |
temtronic
Joined: 01 Jul 2010
Posts: 9170
Location: Greensville,Ontario
|
|
| Posted: Mon Aug 29, 2016 4:46 pm |
|
|
I don't use that PIC or bootloaders now but I suspect you haven't 'write protected' the pages of 'good/original' code so the 'erase' function is wiping out the entire memory ?
Jay |
|
|
m4rcdbk
Joined: 29 Aug 2016
Posts: 10
Location: Michigan, USA
|
|
| Posted: Mon Aug 29, 2016 5:13 pm |
|
|
The inspection of the original ROM shows that my last "used" page ends on 0x63FE. I also have the no code protect and what not fuses in place.
I only erase the zone from 6400 to 0x157FC. The area from 603D to 0x63FE are all 0xFF's.
I'm thinking it has something to do with the debugging parameters; since if I disable the device ICD=2, DEBUG and JTAG directives it boots properly -- I just have no way of seeing the in's and outs. |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Mon Aug 29, 2016 10:42 pm |
|
|
| Quote: | | write the configuration bits that indicate we have additional boot firmware, |
"Configuration Bits" has a very specific meaning in the PIC world.
What you really mean is "write a marker byte in Flash memory..."
| Quote: |
The execution does not stop for some reason, and runs right into the ROM
that has the magic number |
This is hard to understand. Code execution is very deterministic. It
executes instructions sequentially unless it hits a jump, branch, etc.
It doesn't leave an existing code block in Flash and randomly jump
into another code block that is not part of the program. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19359
|
|
| Posted: Tue Aug 30, 2016 12:53 am |
|
|
You can't actually 'do' what you are describing:
"I only erase the zone from 6400 to 0x157FC".
Erases take place in pages of 512 instructions at a time. So an erase can't 'end' at 0x157FC.
However even if it did, it'd be erasing part of the configuration data:
| Code: |
TABLE 4-1: FLASH CONFIGURATION
WORDS FOR
PIC24FJ128GA310 FAMILY
DEVICES
PIC24FJ128GA3XX 44,032 0157F8h:0157FEh
|
Why are you erasing memory?. You do understand that every erase cycle, costs a 'life' of the flash memory. Also that the chip _is_ erased when you start. Unless you have written something into an address, it is already erased. The erased state, is 0xFF.
If you must erase, then stop at the page boundary below the configuration data.
However if you are going to do this, ensure you tell the compiler that you want this area reserved. Otherwise it will put things like text data tables at the top of memory. You may well be erasing these..... |
|
|
m4rcdbk
Joined: 29 Aug 2016
Posts: 10
Location: Michigan, USA
|
|
| Posted: Tue Aug 30, 2016 10:08 am |
|
|
Group,
I apologize; my mind's been a bit of a hamster on a wheel lately and in my haste to get my issue out here I didn't thoroughly explain how and why I'm doing things. Let me address the concerns to hopefully clear some things up.
| PCM programmer wrote: | "Configuration Bits" has a very specific meaning in the PIC world.
What you really mean is "write a marker byte in Flash memory..." |
Correct; What I should have (and meant to convey) was write my own user maker-byte(s) to flash memory. These markers keeping track of how many writes/erases have occurred, various re-flash status, the erase page the new firmware belong to and what-not.
| PCM programmer wrote: | This is hard to understand. Code execution is very deterministic. It
executes instructions sequentially unless it hits a jump, branch, etc.
It doesn't leave an existing code block in Flash and randomly jump
into another code block that is not part of the program. |
Indeed -- It's well beyond the end of the program (approximately 1024 words) and shouldn't have any sort of bearing on the execution of the code. Especially since (in my mind) the code is self manged. By that I mean that it knows all of it's addresses for functions and should have 0 reason to jump to an address below the code ROM. Or if it did, for a debugging function, shouldn't have any reason to jump that far. But something is fishy with that I feel.
| Ttelmah wrote: | You can't actually 'do' what you are describing:
"I only erase the zone from 6400 to 0x157FC".
Erases take place in pages of 512 instructions at a time. So an erase can't 'end' at 0x157FC.
However even if it did, it'd be erasing part of the configuration data:
| Code: | Code
TABLE 4-1: FLASH CONFIGURATION
WORDS FOR
PIC24FJ128GA310 FAMILY
DEVICES
PIC24FJ128GA3XX 44,032 0157F8h:0157FEh |
|
You are correct; however according to the spec sheet the PIC24FJ127GA010's configuration words are at 0x157FE - 0x15800; unless I'm misreading this table. (Figure 4-1 http://ww1.microchip.com/downloads/en/DeviceDoc/39747F.pdf.
However, I also apologize: I misrepresented how I was erasing it.
I should have said: | Quote: | | I am erasing 1 page after the current code page, determined by 8+ concurrent 0xFFFFFF's in ROM. I am erasing the Page after the former, up to but not including the page including the page containing the configuration words |
| Ttelmah wrote: | | Why are you erasing memory?. You do understand that every erase cycle, costs a 'life' of the flash memory. Also that the chip _is_ erased when you start. Unless you have written something into an address, it is already erased. The erased state, is 0xFF. |
Also correct, 1000 write/erase cycles according to the spec sheet. In production it won't be erased since I also understand that a write that takes place on a new page (or boundary of?) also initiates an erase as well -- this is implemented just for testing and what not. Mostly since I anticipate some sort of late night shenanigans where I write to locations I don't need to and so that I can be sure that when I read the fimware back from the PIC to compare the new loaded zone, that I don't get data that I don't exactly need/want.
Hopefully this clears up a few things I may not have represented as intended/unclearly. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19359
|
|
| Posted: Wed Aug 31, 2016 1:13 am |
|
|
This is one of those 'slightly more complex' bits.
The 'configuration area', comprises the chip ID, and the configuration words. The ID starts at 0x15F7C.
However ignore this (doesn't matter), what matters is that you should not be erasing the last page of memory.
In the data sheet:
| Quote: |
Note: Performing a page erase operation on the
last page of program memory clears the
Flash Configuration Words, enabling code
protection as a result. Therefore, users
should avoid performing page erase
operations on the last page of program
memory.
|
Section 29.1.1
Basically don't erase the last page of program memory. Doing so will cause problems..... |
|
|
m4rcdbk
Joined: 29 Aug 2016
Posts: 10
Location: Michigan, USA
|
|
| Posted: Wed Aug 31, 2016 1:32 am |
|
|
Definitely understand that one. The sheet says there are 86 erase pages on the chip, I'm sure to erase only up to page 84 leaving the last 2 untouched. Not that I touch the top of the ROM either; so far I'm just going from page 31 to page 84.
As for my original issue, seems like if I read the page prior to writing to it, all goes according to plan. Doesn't directly explain why being in debug mode makes a difference; but that could just be a padding thing from the directive I suppose. |
|
|
|
|
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
