| View previous topic :: View next topic |
| Author |
Message |
bschriek
Joined: 18 Dec 2007
Posts: 76
|
| Hex file in wrong device. |
 Posted: Tue May 09, 2023 1:57 am |
 |
|
I have a question and I want to know if there is some code I can add to the program to prevent the problem underneath:
We can load a .hex file for the 10F320 device and program into a 10F322 device.
After programming we checked the circuitry and everything works fine.
Is there some code I can add to the program of the 10F320 which will prevent the program to run at the 10F322?
What are the risks when people program a 10F322 device while the firmware is made for a 10F320 device? It seems to work fine but I think we all agree it's not good. |
|
 |
Ttelmah
Joined: 11 Mar 2010
Posts: 19215
|
|
| Posted: Tue May 09, 2023 3:00 am |
|
|
The programmer should have complained, because the device ID didn't
match. However in code terms, nothing, except make the code larger.
The only difference between the 320, and the 322, is the ROM size.
They are otherwise identical chips. Same peripherals etc.. However the
322 has 512bytes of ROM, and the 320 only 256. So if the program is
256bytes or less, it'll run fine in the smaller chip. |
|
|
bschriek
Joined: 18 Dec 2007
Posts: 76
|
|
| Posted: Tue May 09, 2023 3:30 am |
|
|
Sorry, I was not clear about the used programmer.
You are right, CCSload generates a warning but the Pickit 4 does NOT.
Additional I want to find a way to prevent against this fault even when all warnings are neglected.
There must be a way to prevent the µcontroller to run the program while programmed with the wrong .hex file or visaversa.
All circuits are tested after programming so if the program doesn't run then at least this will be noticed during the test.
Thank you in advance, |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9097
Location: Greensville,Ontario
|
|
| Posted: Tue May 09, 2023 5:01 am |
|
|
hmm, providing you have some code space left, your program could read the device ID (0x2006 ? ) and then decide to run or not.
There's also 4 bytes available for 'checksum or user info'.
The problem I see if it's a small PIC so maybe not enough memory for the code. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19215
|
|
| Posted: Tue May 09, 2023 5:28 am |
|
|
I think something like this should work:
| Code: |
#ROM 0x1fE = {4};
void main(void)
{
int val;
read_program_memory(0x1FE,&val,1);
if (val!=4)
reset_cpu();
|
That should fail on the smaller chip.
In fact, the PIcKit4 should fail to program correctly, if you just add:
#ROM 0x1fE = {4};
To the code.
That will try to write a byte to the top of the ROM, and on the smaller
chip this will fail, so the chip won't verify. |
|
|
bschriek
Joined: 18 Dec 2007
Posts: 76
|
|
| Posted: Tue May 09, 2023 6:20 am |
|
|
Thank you Temtronic and Ttelmah. Memory is not the problem.
#Ttelmah; OK, this will work for the small chip only.
#Temtronic; We have a checksum and we copy the checksum to the 4 User ID bits (2000h-2003h).
But the Device ID is a good idea.
The memory location 2006h is where the Device ID and Revision ID are stored. The upper nine bits hold the Device ID.
PIC10F320 = 10 1001 101 and PIC10F322 = 10 1001 100 <13:5>bits
I'm sorry but I don't know how to read the upper nine bits of the Device ID and how to compare this information to the expected Device ID.
I found an old thread from 2003...... and here the #define is used.
I'm thinking of #define DEVID_ADDR 0x2006L and then just compare to 0b101001101xxxxx for the 10F320. |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19215
|
|
| Posted: Wed May 10, 2023 1:43 am |
|
|
OK.
Unfortunately, on this chip CCS don't offer the read_configuration_memory
function. This is only available on the larger PIC's. The read_program_memory
function only supports accessing the lower 512 bytes of ROM, so you would
need to write your own function to access the configuration area.
Something like (no guarantees):
| Code: |
#word PMADR = getenv("SFR:PMADRL")
#word PMDAT = getenv("SFR:PMDATL")
#byte PMCON1 =getenv("SFR:PMCON1")
#bit RD = PMCON1.0 //read command
#bit CFGS = PMCON1.6 //config space selection
int16 read_config_word(void)
{
//read the config word
//Unfortunately the read_configuration function is not available on this
//chip. The standard program memory read can only access 512bytes,
//so we have to go DIY.
//interrupts must be disabled when this is called.
int16 rval;
PMADR=6; //address required xxxxx6
CFGS=TRUE; //select config space
RD=TRUE; //trigger read
delay_cycles(1); //nop
delay_cycles(1); //nop
rval=PMDAT; //read the value
CFGS=FALSE; //ensure standard memory re-selected
return rval;
}
void main(void)
{
int16 val;
val=read_config_word(); //read the 14bit configurations value
val>>=5; //get the device ID (upper 9 bits)
val&=0x1FF; //mask just 9 bits
if (val!=0b101001100) //test for 10F322
reset_cpu(); //stop running if wrong
|
The assembler this generates, looks correct for the config memory read. |
|
|
bschriek
Joined: 18 Dec 2007
Posts: 76
|
|
| Posted: Wed May 10, 2023 2:54 am |
|
|
Wow, thank you for your explanation and code.
I need some time to investigate and try your code example.
Thank you again for your support! |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
