From: M L <mar...@gm...> - 2014-02-13 11:11:14
|
Hi, nonreentrant support function is the likely cause, but AFAIK --stack-auto is not supported on pic14 port so recompiling support functions with --int-long-reent is meaningless , right? 2014-02-13 11:15 GMT+01:00, Maarten Brock <sou...@ds...>: > Hi, > > What you experience here is probably that multiplication is done in a > non-reentrant support function. While it is executing a multiplication in > the mainline it gets interrupted and reuses the multiplication variables > in the support function which effectively destroys the original > multiplication. > > Maarten > >> Hello, >> when testing it with pic16f648a I found other issue, maybe related. >> When such big code array is accessed with int index inside an >> interrupt routine, retrieving values from other arrays located in ram >> (used with other functions and not ralated to interrupt routine) are >> randomly corrupted. When I comment out line with code array >> retrieving: >> // x = my_data[index][0] ; >> ram arrays return values are not corrupted. >> >> Even declaring static index like: >> x = my_data[33][0] ; >> won't prevent wrong values retrieved from ram arrays . >> >> First I thought is related to small stack size (default 16) but >> increasing stack (e.g --stack-size 32 ) makes it worse, code behaves >> odd. >> >> regards, >> ML >> >> 2014-02-12 22:20 GMT+01:00, Raphael Neider <rn...@we...>: >>> Hi, >>> >>> I think that your analysis of the index exceeding 8 bit is correct. >>> Thanks >>> to your analysis of a larger index type yielding correct values this bug >>> should be easier to fix than I initially assumed: indexing with types >>> longer than 8 bit seem to work, I "only" need to make index computations >>> use a large enough type (internally). >>> >>> I'll try to look into this over the weekend. >>> >>> Thank you for the report and the analysis! >>> >>> Raphael >>> On Feb 12, 2014 7:32 PM, "M L" <mar...@gm...> wrote: >>> >>>> Hello, >>>> AFAIK it possible put static (const) arrays like bitmaps in code >>>> memory (values are retrived by retlw instruction internally with sdcc >>>> helpers function), here goes definition of my_data array: >>>> >>>> static __code unsigned char my_data[95][7] >> { >>>> {0x95,0x01,0x78,0x67,0x12,0x88,0x11}, {...}}; >>>> >>>> >>>> I inspected .lst file and whole table is coded correctly in code >>>> memory, starting addres is 0x6f and last address is 0x307: >>>> >>>> 00006f 3495 retlw 0x95 >>>> 000070 3401 retlw 0x1 >>>> 000071 3478 retlw 0x78 >>>> 000072 3467 retlw 0x67 >>>> 000073 3412 retlw 0x12 >>>> 000074 3488 retlw 0x88 >>>> 000075 3411 retlw 0x11 >>>> .... >>>> >>>> Looks like unsigned char index has problem accesing 37th element of >>>> such >>>> array, >>>> example: >>>> unsigned char index; >>>> index=36; >>>> my_data[index][0] -> value OK >>>> index= 37; >>>> my_data[index][0] -> wrong value, >>>> >>>> but when I declare: >>>> unsigned int index; >>>> >>>> index=36; >>>> my_data[index][0] -> value OK >>>> index= 37; >>>> my_data[index][0] -> value OK, >>>> >>>> So wrong values retrieved with char type index may be related to wrong >>>> offset calculation for call to retlw instruction inside sdcc, like >>>> this: >>>> 36*7 = 252 >>>> 37*7 = 259 -> value beyond 8bit char type, index will be wrapped to 3 >>>> >>>> >>>> regards, >>>> mb >>>> >>>> 2014-02-12 18:33 GMT+01:00, Gál Zsolt <tra...@fr...>: >>>> > Hello MB, >>>> > >>>> > Could you write more detail about definition of array? As I know, all >>>> > variables takes places in data memory not in code memory. You should >>>> > give >>>> > modification word for defining variables in code memory. So this is >>>> > littlebit more complicated. >>>> > >>>> > The other point is the size of your array. If its type is char, its >>>> > size >>>> > will be 95x7 = 665 bytes ( or words if it is takes place in code >>>> memory >>>> ). >>>> > I think array is bigger those size what a pic14 device can handle. >>>> > >>>> > Zsolt >>>> > >>>> > >>>> > 2014-02-12 17:20 GMT+01:00 M L <mar...@gm...>: >>>> > >>>> >> Hello, >>>> >> I have a 2 dimensional array with static values: unsigned char >>>> >> my_tab[95][7] ={ ..} and it's located in a code memory. When I >>>> read >>>> >> array with the following code: >>>> >> >>>> >> unigned char index, v; >>>> >> >>>> >> { index is computed ...} >>>> >> v=my_tab[index][0]; >>>> >> >>>> >> >>>> >> my "v" has unexpected value when computed index is above 36. When I >>>> >> change index to unisgned int, values readings are as expected. Is >>>> >> there any know issues with array index variables in pic14 port? >>>> >> >>>> >> regards, >>>> >> mb > > > ------------------------------------------------------------------------------ > Android apps run on BlackBerry 10 > Introducing the new BlackBerry 10.2.1 Runtime for Android apps. > Now with support for Jelly Bean, Bluetooth, Mapview and more. > Get your Android app in front of a whole new audience. Start now. > http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user > |