aafree 0 Report post Posted May 23, 2013 I am working on a SMBuss project that targets the PIC18F27J53 using the BoostC (ver7.04) in MPLAB (ver8.87). I am using a 256 byte lookup table for generating the CRC (PEC). The lookup table is not generating the correct offset and I'm not sure why. I have generalized the problem to reduce confusion. In the main while() loop I have "crc=CRC8LKUP[0xB4] ;" when I look at the listing file, line 134, the index is changed from 0xB4 to 0x68. Attached are the relivant files. Anybody have an idea what is going on? ;/////////////////////////////////////////////////////////////////////////////////;// Code Generator: BoostC Compiler - http://www.sourceboost.com;// Version : 7.04;// License Type : Standard License;// Limitations : PIC18 max code size:16384 bytes, max RAM banks:Unlimited, Non commercial use only;///////////////////////////////////////////////////////////////////////////////// ORG 0x000000000000 EFA0F000 GOTO _startup ORG 0x000000080008 __rom_get_000000008 ; { __rom_get ; function begin0008 5005 MOVF __rom_get_00000_arg_idx, W000A 6E08 MOVWF __rom_get_00000_1_romAddr+D'2'000C 0E00 MOVLW UPPER( label1 )000E 6EF8 MOVWF TBLPTRU0010 0E00 MOVLW HIGH( label1 )0012 6EF7 MOVWF TBLPTRH0014 0E2A MOVLW LOW( label1 )0016 6EF6 MOVWF TBLPTRL0018 5008 MOVF __rom_get_00000_1_romAddr+D'2', W001A 26F6 ADDWF TBLPTRL, F001C B0D8 BTFSC STATUS,C001E 2AF7 INCF TBLPTRH, F0020 B0D8 BTFSC STATUS,C0022 2AF8 INCF TBLPTRU, F0024 0008 TBLRD*0026 50F5 MOVF TABLAT, W0028 0012 RETURN002A label1002A 0700 DW 0x0700002C 090E DW 0x090E002E 1B1C DW 0x1B1C0030 1512 DW 0x15120032 3F38 DW 0x3F380034 3136 DW 0x31360036 2324 DW 0x23240038 2D2A DW 0x2D2A003A 7770 DW 0x7770003C 797E DW 0x797E003E 6B6C DW 0x6B6C0040 6562 DW 0x65620042 4F48 DW 0x4F480044 4146 DW 0x41460046 5354 DW 0x53540048 5D5A DW 0x5D5A004A E7E0 DW 0xE7E0004C E9EE DW 0xE9EE004E FBFC DW 0xFBFC0050 F5F2 DW 0xF5F20052 DFD8 DW 0xDFD80054 D1D6 DW 0xD1D60056 C3C4 DW 0xC3C40058 CDCA DW 0xCDCA005A 9790 DW 0x9790005C 999E DW 0x999E005E 8B8C DW 0x8B8C0060 8582 DW 0x85820062 AFA8 DW 0xAFA80064 A1A6 DW 0xA1A60066 B3B4 DW 0xB3B40068 BDBA DW 0xBDBA006A C0C7 DW 0xC0C7006C CEC9 DW 0xCEC9006E DCDB DW 0xDCDB0070 D2D5 DW 0xD2D50072 F8FF DW 0xF8FF0074 F6F1 DW 0xF6F10076 E4E3 DW 0xE4E30078 EAED DW 0xEAED007A B0B7 DW 0xB0B7007C BEB9 DW 0xBEB9007E ACAB DW 0xACAB0080 A2A5 DW 0xA2A50082 888F DW 0x888F0084 8681 DW 0x86810086 9493 DW 0x94930088 9A9D DW 0x9A9D008A 2027 DW 0x2027008C 2E29 DW 0x2E29008E 3C3B DW 0x3C3B0090 3235 DW 0x32350092 181F DW 0x181F0094 1611 DW 0x16110096 0403 DW 0x04030098 0A0D DW 0x0A0D009A 5057 DW 0x5057009C 5E59 DW 0x5E59009E 4C4B DW 0x4C4B00A0 4245 DW 0x424500A2 686F DW 0x686F00A4 6661 DW 0x666100A6 7473 DW 0x747300A8 7A7D DW 0x7A7D00AA 8E89 DW 0x8E8900AC 8087 DW 0x808700AE 9295 DW 0x929500B0 9C9B DW 0x9C9B00B2 B6B1 DW 0xB6B100B4 B8BF DW 0xB8BF00B6 AAAD DW 0xAAAD00B8 A4A3 DW 0xA4A300BA FEF9 DW 0xFEF900BC F0F7 DW 0xF0F700BE E2E5 DW 0xE2E500C0 ECEB DW 0xECEB00C2 C6C1 DW 0xC6C100C4 C8CF DW 0xC8CF00C6 DADD DW 0xDADD00C8 D4D3 DW 0xD4D300CA 6E69 DW 0x6E6900CC 6067 DW 0x606700CE 7275 DW 0x727500D0 7C7B DW 0x7C7B00D2 5651 DW 0x565100D4 585F DW 0x585F00D6 4A4D DW 0x4A4D00D8 4443 DW 0x444300DA 1E19 DW 0x1E1900DC 1017 DW 0x101700DE 0205 DW 0x020500E0 0C0B DW 0x0C0B00E2 2621 DW 0x262100E4 282F DW 0x282F00E6 3A3D DW 0x3A3D00E8 3433 DW 0x343300EA 494E DW 0x494E00EC 4740 DW 0x474000EE 5552 DW 0x555200F0 5B5C DW 0x5B5C00F2 7176 DW 0x717600F4 7F78 DW 0x7F7800F6 6D6A DW 0x6D6A00F8 6364 DW 0x636400FA 393E DW 0x393E00FC 3730 DW 0x373000FE 2522 DW 0x25220100 2B2C DW 0x2B2C0102 0106 DW 0x01060104 0F08 DW 0x0F080106 1D1A DW 0x1D1A0108 1314 DW 0x1314010A A9AE DW 0xA9AE010C A7A0 DW 0xA7A0010E B5B2 DW 0xB5B20110 BBBC DW 0xBBBC0112 9196 DW 0x91960114 9F98 DW 0x9F980116 8D8A DW 0x8D8A0118 8384 DW 0x8384011A D9DE DW 0xD9DE011C D7D0 DW 0xD7D0011E C5C2 DW 0xC5C20120 CBCC DW 0xCBCC0122 E1E6 DW 0xE1E60124 EFE8 DW 0xEFE80126 FDFA DW 0xFDFA0128 F3F4 DW 0xF3F4012A ; } __rom_get function end ORG 0x0000012A012A main012A ; { main ; function begin012A 6A01 CLRF gbl_3_x012C 6A02 CLRF gbl_3_x+D'1'012E label2012E 0101 MOVLB 0x010130 5100 MOVF gbl_CRC8LKUP, W, 10132 6E04 MOVWF __rom_get_00000_arg_objNumb0134 0E68 MOVLW 0x680136 6E05 MOVWF __rom_get_00000_arg_idx0138 EC04F000 CALL __rom_get_00000013C 6E03 MOVWF gbl_3_crc013E D7F7 BRA label20140 ; } main function end ORG 0x000001400140 _startup0140 0E00 MOVLW 0x000142 0101 MOVLB 0x010144 6F00 MOVWF gbl_CRC8LKUP, 10146 6A01 CLRF gbl_3_x0148 6A02 CLRF gbl_3_x+D'1'014A 6A03 CLRF gbl_3_crc014C EF95F000 GOTO main ORG 0x0001FFF81FFF8 071C DW 0x071C1FFFA 0018 DW 0x00181FFFC 0000 DW 0x00001FFFE 0980 DW 0x0980 MAIN.C CRC8.H IC.H Quote Share this post Link to post Share on other sites
aafree 0 Report post Posted May 24, 2013 Not sure what the differences are between these two ways of declaring a ROM table rom char *MYTABLE[] = { somedata } ; // Compiler generates code to double the value you give, as if all elements in the table are word aligned or rom const char[] = { somedata } ; // Compiler allows elements in table to be accessed using byte alignment Any insite? I found my fix so this thread is done. Quote Share this post Link to post Share on other sites
JorgeF 0 Report post Posted May 24, 2013 Hi Probably this happens because you are using a PIC that can do self-write of program flash memory. So when you don't use the "const" modifier it aligns the data in a way that's compatible with a simple program flash write procedure. I'm more or less gessing, but it makes sense for me. Best regards Jorge Quote Share this post Link to post Share on other sites
trossin 0 Report post Posted March 2, 2018 Just got burned again on an 18F2620: If I use: rom const char table[]= { ....}; it chews up RAM If I use: rom const char *table = {....}; it does not chew up RAM Using Version 7.22. It is bad enough that I have to break my tables up into tiny 256 byte pieces but until I found this secret, I was ready to go to the dark side (Microchip compiler). Quote Share this post Link to post Share on other sites
Guest Chris Report post Posted August 20 On 3/2/2018 at 8:57 PM, trossin said: Just got burned again on an 18F2620: If I use: rom const char table[]= { ....}; it chews up RAM If I use: rom const char *table = {....}; it does not chew up RAM Using Version 7.22. It is bad enough that I have to break my tables up into tiny 256 byte pieces but until I found this secret, I was ready to go to the dark side (Microchip compiler). Much kudos to you. You saved my live. I also banged my head for half a day on this. What a difference a star (*) can make to []. Quote Share this post Link to post Share on other sites
