#rom statement bug 5.044

rwalborn · Joined: 12 Dec 2011 Posts: 8 Location: USA

i found a compiler bug in the 5.044 compiler when using the PIC24EP512GU810 processor but it may affect other processors.

I found that if i used a #rom statement like
#ROM char 0X3400 = {"AMC RACK 4.00 04/01/2015"}
the last two bytes in the statement can overwrite sections of the code.

This has been reported to CCS and they are fixing in the next release.

If you are using #rom statements check the listing file to see if this is happening.

As a work around I found that adding an extra space at the end of text string prevented the problem.

jeremiah · Joined: 20 Jul 2010 Posts: 1358

Does this apply to all #rom statements or only ones with char strings?

rwalborn · Joined: 12 Dec 2011 Posts: 8 Location: USA

I don't know. I found it while using text string. I have not tried it with anything else.

Ttelmah · Joined: 11 Mar 2010 Posts: 19552

It seems unlikely that it is behaving quiet as you describe. If it was, adding the spaces wouldn't solve anything, since the spaces would still be overwriting things....
I'd suspect it relates to the instruction word size, versus char. An instruction in the PIC24, is 24bits long, occupying 32bits in the memory space. So your 24 character (plus terminator) string, needs to use nine instructions (32bytes in the memory space) The next two bytes _will_ be part of the same instruction word, so 'of course' they will be overwritten. However the compiler itself will not use these. Are you attempting to put something else yourself there?. If so, you need to realise that things do need to be instruction aligned.
Adding two more characters, takes the total size to 27 bytes, which fills to the 9 instruction boundary accurately.

rwalborn · Joined: 12 Dec 2011 Posts: 8 Location: USA

I was doing the text string. One more space solved the problem (at least for now).

CCS support only took about 1/2 hour to identify the problem and correct it for the next release.