CW 08 V3.1 - Declaring value for FLBPR in C source for MR32 bootloader

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

CW 08 V3.1 - Declaring value for FLBPR in C source for MR32 bootloader

Jump to solution
3,792 Views
wre
Contributor III
What is the correct way to set the value of FLBPR (Flash Block Protection Register) in C source targetting a 908MR32 device?
 
I have written a bootloader and now want to set the value of FLBPR to protect the FLASH area where the bootloader resides.
 
Thanks,
 
Bill
 
Labels (1)
Tags (1)
0 Kudos
1 Solution
940 Views
CrasyCat
Specialist III

OK I think I know what is going on here.

In fact the register _FLBPR is already defined in the MC68HC908MR32.h and MC68HC908MR32.c.
So you have two objects allocated there and the linker takes the first definition (the one of MC68HC908MR32.c).

To fix that I see 3 solutions:
1- make sure the linker takes your definition
    To achieve that:
       - Open the project in CodeWarrior
       - Switch to "Link Order" view
       - Make sure your source file comes prior to  MC68HC908MR32.c file in the tab.
         Just drag it on top of the list.
    I am not sure this will work, but it might be worth it to give it a try.

2- Modify definition of  _FLBPR in MC68HC908MR32.c
  To achieve that:
      - Copy the file MC68HC908MR32.c locally to your project source directory
      - Edit the file MC68HC908MR32.c and modify the definition as follows:
             volatile FLBPRSTR _FLBPR = 0xE8;                                  /* FLASH Block Protect Register */

3- remove the definition from file MC68HC908MR32
  To achieve that:
      - Copy the files MC68HC908MR32.h & MC68HC908MR32.c locally to your project source directory
      - Edit the file MC68HC908MR32.h and remove or comment out the lines:

Code:
extern volatile FLBPRSTR _FLBPR @0x0000FF7E;#define FLBPR _FLBPR.Byte#define FLBPR_BPR0 _FLBPR.Bits.BPR0#define FLBPR_BPR1 _FLBPR.Bits.BPR1#define FLBPR_BPR2 _FLBPR.Bits.BPR2#define FLBPR_BPR3 _FLBPR.Bits.BPR3#define FLBPR_BPR4 _FLBPR.Bits.BPR4#define FLBPR_BPR5 _FLBPR.Bits.BPR5#define FLBPR_BPR6 _FLBPR.Bits.BPR6#define FLBPR_BPR7 _FLBPR.Bits.BPR7#define FLBPR_BPR _FLBPR.MergedBits.grpBPR#define FLBPR_BPR0_MASK   1#define FLBPR_BPR0_BITNUM 0#define FLBPR_BPR1_MASK   2#define FLBPR_BPR1_BITNUM 1#define FLBPR_BPR2_MASK   4#define FLBPR_BPR2_BITNUM 2#define FLBPR_BPR3_MASK   8#define FLBPR_BPR3_BITNUM 3#define FLBPR_BPR4_MASK   16#define FLBPR_BPR4_BITNUM 4#define FLBPR_BPR5_MASK   32#define FLBPR_BPR5_BITNUM 5#define FLBPR_BPR6_MASK   64#define FLBPR_BPR6_BITNUM 6#define FLBPR_BPR7_MASK   128#define FLBPR_BPR7_BITNUM 7#define FLBPR_BPR_MASK  255#define FLBPR_BPR_BITNUM  0


 
   - Edit file MC68HC908MR32.c file and comment out the line
             volatile FLBPRSTR _FLBPR;                                  /* FLASH Block Protect Register */

CrasyCat

View solution in original post

0 Kudos
9 Replies
940 Views
RockyRoad
Contributor III

Bill -

Try:

const char FLBPR @ 0xFF7E=0xXX

where XX is the hex value to set the desired protection.

- Rocky

0 Kudos
940 Views
wre
Contributor III

Thanks for the response.  When I try your suggestion I get an Error C1019 "Incompatible type to previous declaration...".

This is due to this declaration in MC68HC908MR32.h:

[snip]

extern volatile FLBPRSTR _FLBPR @0x0000FF7E;
#define FLBPR _FLBPR.Byte
[snip]

It looks like I may need to have two declarations for the same register...something I was trying to avoid for clarity (and purity).

Any other thoughts?

Bill

 

0 Kudos
940 Views
wre
Contributor III

I am presently using:

const char xFLBPR @ 0xFF7E=0xE8;

My understanding is that this byte value will need to be programmed at the same time as the bootloader and therefore needs to be part of the .S19 file.  There is no .S19 data for the FF7E address.

Since it is not referenced in the code, I added xFLBPR to the ENTRIES section of the linker file but that didn't solve the problem...still no data in the .S19 file.

I have also tried creating a segment for that one byte...still no success.

This can't be that hard!

 

0 Kudos
940 Views
CrasyCat
Specialist III

That should be working. It seems there is something in your project generating some trouble.

Did you check the application .map file?

Is there anything allocated at address 0xFF7E there?

CrasyCat

0 Kudos
940 Views
wre
Contributor III

Hi.  Here is what is in the .MAP file:

    xFLBPR                                    FF7E       1       1       0   .abs_section_ff7e
    _FLBPR                                    FF7E       1       1       2   .abs_section_ff7e

And here are the relevent records of the .S19 file:

S123FCBB50616765204572617365203078002E0A00446174612050726F67203078002E0A66
S10EFCDB000D0A00000100630300009C
S123FFD2F3BBF3BEF3C1F3C4F3C7F3CAF3CDF3D0F3D3F3D6F3D9F3DCF3DFF3E2F3E5F3E8C3
S111FFF2F3EBF3EEF3F1F3F4F3F7F3FAF48C1C
S9030000FC

Bill

0 Kudos
941 Views
CrasyCat
Specialist III

OK I think I know what is going on here.

In fact the register _FLBPR is already defined in the MC68HC908MR32.h and MC68HC908MR32.c.
So you have two objects allocated there and the linker takes the first definition (the one of MC68HC908MR32.c).

To fix that I see 3 solutions:
1- make sure the linker takes your definition
    To achieve that:
       - Open the project in CodeWarrior
       - Switch to "Link Order" view
       - Make sure your source file comes prior to  MC68HC908MR32.c file in the tab.
         Just drag it on top of the list.
    I am not sure this will work, but it might be worth it to give it a try.

2- Modify definition of  _FLBPR in MC68HC908MR32.c
  To achieve that:
      - Copy the file MC68HC908MR32.c locally to your project source directory
      - Edit the file MC68HC908MR32.c and modify the definition as follows:
             volatile FLBPRSTR _FLBPR = 0xE8;                                  /* FLASH Block Protect Register */

3- remove the definition from file MC68HC908MR32
  To achieve that:
      - Copy the files MC68HC908MR32.h & MC68HC908MR32.c locally to your project source directory
      - Edit the file MC68HC908MR32.h and remove or comment out the lines:

Code:
extern volatile FLBPRSTR _FLBPR @0x0000FF7E;#define FLBPR _FLBPR.Byte#define FLBPR_BPR0 _FLBPR.Bits.BPR0#define FLBPR_BPR1 _FLBPR.Bits.BPR1#define FLBPR_BPR2 _FLBPR.Bits.BPR2#define FLBPR_BPR3 _FLBPR.Bits.BPR3#define FLBPR_BPR4 _FLBPR.Bits.BPR4#define FLBPR_BPR5 _FLBPR.Bits.BPR5#define FLBPR_BPR6 _FLBPR.Bits.BPR6#define FLBPR_BPR7 _FLBPR.Bits.BPR7#define FLBPR_BPR _FLBPR.MergedBits.grpBPR#define FLBPR_BPR0_MASK   1#define FLBPR_BPR0_BITNUM 0#define FLBPR_BPR1_MASK   2#define FLBPR_BPR1_BITNUM 1#define FLBPR_BPR2_MASK   4#define FLBPR_BPR2_BITNUM 2#define FLBPR_BPR3_MASK   8#define FLBPR_BPR3_BITNUM 3#define FLBPR_BPR4_MASK   16#define FLBPR_BPR4_BITNUM 4#define FLBPR_BPR5_MASK   32#define FLBPR_BPR5_BITNUM 5#define FLBPR_BPR6_MASK   64#define FLBPR_BPR6_BITNUM 6#define FLBPR_BPR7_MASK   128#define FLBPR_BPR7_BITNUM 7#define FLBPR_BPR_MASK  255#define FLBPR_BPR_BITNUM  0


 
   - Edit file MC68HC908MR32.c file and comment out the line
             volatile FLBPRSTR _FLBPR;                                  /* FLASH Block Protect Register */

CrasyCat

0 Kudos
940 Views
wre
Contributor III

I appreciate your timely response.  I would like to work through the first suggestion first as I would like to leave everything as "normal" as possible...so I don't want to edit the files that came with CW.

I have changed the link order and get the following errors:

L1112: The .abs_section_ff7e section has segment type NO_INIT (illegal)

L1934: ELF: Section '.abs_section_ff7e' located in a segment with invalid qualifier.

It is not clear to me where the .abs_section_ff7e comes from unless it is from the declaration of xFLBPR and is triggering off of the word 'const':

const Uint8 xFLBPR @ 0xFF7E = 0xE8;  /* F400 to FFFF protected */

But why is NO_INIT illegal for this?

Does this provide enough evidence that this first option won't work (I hope not) or are there some other things that need to be looked at?  

wre

0 Kudos
940 Views
CrasyCat
Specialist III

Hello

That simply shows that solution 1 does not work. You will have to go with 2 or 3.

CrasyCat

0 Kudos
940 Views
wre
Contributor III
Thanks for your help.  I ended up using option 3.
 
 
0 Kudos