Jump to content

Recommended Posts

I recently had a problem with arrays held in RAM being corrupted, so I thought i would move them to ROM using rom char *. I found that it was still possible to corrupt the array output! Here's what i think happened...  

It looks like the compiler assigns a 256 byte ROM area to every rom char array, regardless of actual size. It then assigns a "rom char array number" (1,2,3, etc) to each array for identification: THEN IT STORES THAT NUMBER IN RAM!

Consequently, if the area of RAM holding the rom char array number is corrupted, then the rom array output is also corrupted (because you are probably looking in the wrong place in ROM).

As a (licenced!) commercial user, it is sometimes necessary to try to ensure the contents of a lookup table or array at all costs. (Yes, I am the first to agree that I should be preventing the overwrite of RAM!). If the above is a correct observation, then

1) this assignment of rom char numbers to RAM is not a good idea-it can be corrupted

2) we seem to be burning 256 bytes of ROM per array regardless of required size, which also does not help in a tight for space application.

Looking at the assembly output, it would seem reasonable to hard code the rom array base address; this would also make it easier to make the arrays only the length they need to be (and leave more code space available).  


Maybe you can take this into consideration if you are revisiting rom char array handling in Chameleon.

(...and it would also be good to be able to assign the contents with 0xnn or \xnn - I think others have reported problems here?) 


Thanks for listening!

Link to post
Share on other sites

Are you using a PIC 16 or PIC 18 ?

My current project is for PIC 18 and I have 70+ rom char arrays both string and byte arrays.  All the arrays are stored consecutively in program memory.

Accessing the arrays is through an index which is a constant.

If my arrays are each occupying 256 bytes I would know about it.

Can you supply Dave and Pavel with code showing what you believe to be experiencing.




Link to post
Share on other sites

Hi Reynard,

I am using PIC18F (45K22). I cant really send you full source code, as these are commercial designs and "the customer's property". But here are some snippets:


This is the code as I have followed it; I know I'm not infallible, and I did try to say "if I'm right" ...(!)    see what you think of my understanding:


Looking in the asm output, a RAM byte is assigned for the array called "sw_id":

gbl_sw_id                        EQU    0x000002FC ; bytes:1             // why!?!?!


Then the _startup code does this:

    MOVLW 0x00
    MOVLB 0x02
    MOVWF gbl_segmap, 1
    MOVLW 0x01
    MOVWF gbl_sw_id, 1
    MOVLW 0x02
    MOVWF gbl_xfm_id, 1
    MOVLW 0x03
    MOVWF gbl_sw_xform, 1
    MOVLW 0x04
    MOVWF gbl_mastermodename, 1
    MOVLW 0x05

... where segmap, sw_id, xfm_id, swxform, mastermodename, are all rom char* arrays.

Isn't this putting an array token number into RAM?


Example: 'C' definition of sw_id array:

//                  0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5  6
//                 <-><-><-><-><-><-><-><-><-><-><-><-><-><-><-><-><->
rom char *sw_id = "CFGDM1MODTD1TU1DM2TU2TD2DSBDSADM3TD3TU3TD4TU4DM4---";



A typical use of the array in 'C' would be 

romstrget(sw_id,start,length,dest_array);         // romstrget is my function which accesses the array at the array position given by "start",

                                                                                 // then copies "length" bytes to "dest_array", terminating in 0x00

At the asm level, the array is accessed  using:

    MOVLB 0x02
    MOVF gbl_sw_id, W, 1
    MOVLB 0x03
    MOVWF romstrget_00000_arg_romstr, 1
    MOVF main_1_j, W, 1
    MULLW 0x03
    MOVWF romstrget_00000_arg_start, 1
    MOVLW 0x03
    MOVWF romstrget_00000_arg_len, 1
    MOVLW HIGH(gbl_msg_tmp+D'0')
    MOVWF romstrget_00000_arg_str+D'1', 1
    MOVLW LOW(gbl_msg_tmp+D'0')
    MOVWF romstrget_00000_arg_str, 1
    CALL romstrget_00000

Isn't MOVF gbl_sw_id,W,1,  attempting to access the rom array using a RAM based token value?

I haven't followed the code to the absolute letter \ byte at this point, so you may be able to set me on the right path...!


Thanks for your time....  still think its a great little compiler, and I'm looking forward to Chameleon...

Link to post
Share on other sites

I have been using SourceBoost for 10 years now and never knew it put all that extra code into the startup section for rom arrays.

I suppose that is because the IDE shows the .casm file which doesn't show all this extra stuff.

We will just have to make sure to write code that doesn't crash and test it well.

Function pointers taking arguments usually causes me problems.  Can't seem to use the arguments unless I copy them into a local first variable.  Maybe it's just me.

But as you say a great little compiler.  Novo is usually in every project I do.




Link to post
Share on other sites

Here are some notes how rom objects work in BoostC:

- a rom object is always identified by one byte (that's why in the code above gbl_sw_id is 1 byte long)

- when linker processes all its input files it makes a list of all rom objects and allocates IDs to them

- linker generates code for all these rom objects that it puts into the code memory

- linker generates a function that can extract any byte of any rom object using its ID and position/index

- when compiler needs to generate code to access character in a rom object it uses an placeholder ID and character position/index and calls function that linker generates in the prev bullet. Later linker replaces this placeholder ID with an actual object ID.


Chameleon does not yet support rom objects. Support for rom objects will be added to Chameleon in the upcoming 7.43 release.




Link to post
Share on other sites

Join the conversation

You are posting as a guest. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...