| View previous topic :: View next topic |
| Author |
Message |
oxo
Joined: 13 Nov 2012
Posts: 219
Location: France
|
| read and write configuration memory |
 Posted: Wed Feb 26, 2014 7:38 am |
 |
|
PIC18F26K80
CCS 5.020
I'm working on a bootloader, and it's all ok, except I have a problem with the config memory.
I have fuses defined:-
| Code: | #fuses NODEBUG //Disable Debug mode for use with ICD
#fuses WDT //Use Watch Dog Timer
#fuses WDT512 //Watch Dog Timer uses 1:512 Postscale
#fuses PUT //Power Up Timer
#fuses BROWNOUT //No brownout reset
#fuses BORV30 //brownout reset voltage at 4.2V
#fuses NOMCLR //Master Clear pin used for I/O
#fuses NOXINST //Extended set extension and Indexed Addressing mode disabled (Legacy mode)
#fuses IESO //Internal External Switch Over mode enabled
#fuses STVREN //Stack full/underflow will cause reset
#fuses FCMEN //Fail-safe clock monitor enabled
#fuses NOWRT //Program memory not write protected
#fuses NOWRTD //Data EEPROM not write protected
#fuses NOCPD //Data EEPROM not code protected
#fuses PROTECT //Code protected from reads
#fuses NOCPB //Boot block not code protected
#fuses NOEBTR //Memory not protected from table reads
#fuses HSH // External oscillator
#use delay(crystal= 16M, clock=64M)
#fuses CANB // CAN on RB2/RB3 |
I read the config memory into a buffer..
| Code: | #define CONFIG_LEN 14
unsigned int8 buffer[CONFIG_LEN];
read_configuration_memory(&buffer, CONFIG_LEN); |
But when I examine the buffer, it does not have the correct values for the fuses selected.
[0] 0x15
[1] 0x52
[2] 0x69
[3] 0x34
.. etc
the values should be :
[0] 0x15
[1] 0xD2
[2] 0x66
[3] 0x27
Anybody got an idea? I am baffled.. |
|
 |
temtronic
Joined: 01 Jul 2010
Posts: 9164
Location: Greensville,Ontario
|
|
| Posted: Wed Feb 26, 2014 8:08 am |
|
|
OK, I don't use that PIC or bootloaders but general comments..
You should post the settings in English in a table, the hexcodes mean nothing except they aren't the same. It's important to know WHICH setting are not correct.
The fuses have to be the same for both your program AND the bootloader. My 'gut feeling' is that the bootloader settings are changing the program settings.Or perhaps MPLAB , or the programmer?
hth
jay |
|
|
asmboy
Joined: 20 Nov 2007
Posts: 2128
Location: albany ny
|
|
| Posted: Wed Feb 26, 2014 8:26 am |
|
|
| Code: |
#fuses BROWNOUT //No brownout reset
#fuses BORV30 //brownout reset voltage at 4.2V
#fuses HSH // External oscillator
#use delay(crystal= 16M, clock=64M)
|
what you coded needs scrutiny.
you say NO but the fuse says YES
you say 4.2v but the fuse says 3v
and lastly is, if you want the fuses to be set in one place - you might call for a 4x PLL in the fuses instead of the the #use delay
but have never set the PLL fuses
are you expecting the compiler to do that?
i prefer to set the fuses directly.
what happens when you explicitly code the fuses you want - NOT using any boot loader nonsense ?? |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19346
|
|
| Posted: Wed Feb 26, 2014 9:01 am |
|
|
I've just tried and they read correctly for me.
15 D2 66 27 00 09 91 00 00 C0 0F E0 0F 40
You get 15 52, if ICD is selected. I'd guess you are compiling through MPLAB, and this is overriding the 'NODEBUG' fuse and setting the chip for DEBUG mode. |
|
|
oxo
Joined: 13 Nov 2012
Posts: 219
Location: France
|
|
| Posted: Wed Feb 26, 2014 9:28 am |
|
|
| Ttelmah wrote: | I've just tried and they read correctly for me.
15 D2 66 27 00 09 91 00 00 C0 0F E0 0F 40
You get 15 52, if ICD is selected. I'd guess you are compiling through MPLAB, and this is overriding the 'NODEBUG' fuse and setting the chip for DEBUG mode. |
Ah...
Yes. I'm running in debug - that's how I can see what the values are.
Thanks. |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9164
Location: Greensville,Ontario
|
|
| Posted: Wed Feb 26, 2014 11:59 am |
|
|
You do not have to be in 'debug' mode to see the bits.
In MPLAB,
1) read the device,
2) select 'configure',
3) select 'configuration bits'
This gives you the 'real world' configuration of 'fuses' or configuration words unlike the erroneous 'debug' values.
hth
jay |
|
|
oxo
Joined: 13 Nov 2012
Posts: 219
Location: France
|
|
| Posted: Thu Feb 27, 2014 1:20 am |
|
|
| I dont use MPlab. I only use CCS IDE and ICD-U64 |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19346
|
|
| Posted: Fri Feb 28, 2014 1:34 am |
|
|
Imagine you haven't got any debugger.
You write a hex file to the chip, and (provided code protection is not enabled), you can then read this back. You can look at the contents of the configuration fuses from the programmer code, and see what the chip would genuinely have in it. To look at what you would see in the 'real world', this is the way to work. You don't need to be in debug mode to see what is in the chip.
If instead you work in 'debug' mode, things alter. There are quite a few things that deliberately have to be changed to work in debug mode. For example, the debugger can't handle the watchdog, so this is explicitly disabled when debug is selected. Generally there is a list of what is changed when debug is selected with the debugger code, or in the Microchip notes. So by selecting ICD or debug, you change what it actually written to the chip. I immediately recognised the changes in the first word, to be those that are made when debug is selected...
Debugging is great for working out how program flow actually runs etc., but when dealing with things like the configuration fuses, you need to be aware of the changes.
The 'point' about MPLAB, is that it will always force the compiler to debug mode, unless you explicitly change it to release mode. Hence it is a common reason for people to 'accidentally' be in debug mode without realising it. However in your case, you are doing the forcing by selecting debug mode, which you don't need..... |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
