mustang
stranger
Reged: Oct 04 2007
Posts: 19
Loc: Greater Boston, MA
|
|
Wow. I've been bothered by this bug for a while. But, until this past week, I was able to avoid the bug and make progress on other parts of my code. I was hoping that the bug would caught and fixed in an upcoming release. But, I guess I wasn't that lucky.
I found that version 9.60 puts the variables in BSS 5. And, this particular bug wasn't present. However, I still had issues with another routine. So, I was banging between the 9.60 and 9.61 versions just so I could make progress.
If needed, I can email direct to hi-tech, the project, and even a video screen capture as I step through the code segment listed below. And, show how the code overwrites another variable. And, any other information needed.
Note that the variable temperture_12bits_uint is a global, and lives in RAM in BSS 4.
Note:
Defined in main.h
unsigned int temperture_12bits_uint = 0;
Code:
11185 line 235
11186 ;temperature_sensor_routines.c: 234: else {
11187 ;temperature_sensor_routines.c: 235: temperture_12bits_uint = (unsigned int) rx_I2C_buffer[0] << 8;
11188 3A38 62 D0 00 mov reg[CUR_PP],0
11189 3A3B 62 D0 04 mov reg[CUR_PP],4
11190 3A3E 5F 31 E7 mov [(??_scan_temperture_sensor_devices^0x0)+7+0],[0+((_rx_I2C_buffer)^0x400)]
11191 3A41 55 32 00 mov [(??_scan_temperture_sensor_devices^0x0)+7+0+1],0
11192 3A44 62 D0 00 mov reg[CUR_PP],0
11193 3A47 51 32 mov a,[(??_scan_temperture_sensor_devices^0x0)+7+1]
11194 3A49 62 D0 04 mov reg[CUR_PP],4
11195 3A4C 53 83 mov [1+((_temperture_12bits_uint)^0x400)],a
11196 3A4E 62 D0 00 mov reg[CUR_PP],0
11197 3A51 51 31 mov a,[(??_scan_temperture_sensor_devices^0x0)+7+0]
11198 3A53 62 D0 04 mov reg[CUR_PP],4
11199 3A56 53 82 mov [0+((_temperture_12bits_uint)^0x400)],a
11200 line 236
I'm now using:
Code:
Linking..
HI-TECH C COMPILER (Cypress PSOC) Pro candidate build 2232 V9.61PL1
Copyright (C) 1984-2008 HI-TECH SOFTWARE
Serial number: info_removed_by_joe :-)
Memory Summary:
Program space used 79FEh ( 31230) of 8000h bytes ( 95.3%)
Data space used 4AEh ( 1198) of 800h bytes ( 58.5%)
Comparative memory usage (excludes absolute areas and stack variables)
ROM used: 30762 bytes
RAM used: 1080 bytes
Thanks in Advance!
Joe
P.S. I know that I spelled temperature wrong in the variable name. 
|
mustang
stranger
Reged: Oct 04 2007
Posts: 19
Loc: Greater Boston, MA
|
|
Ahh, with sleep, I now see what the code is doing and the bug.
The bug is in the following line:
Code:
11189 3A3B 62 D0 04 mov reg[CUR_PP],4
That line should not be there. The code is using the stack to store the value from rx_I2C_buffer. Then, moves that to "a", then moves "a" to temperture_12bits_uint. The stack is in CUR_PP 0. But, that extra CUR_PP change is now making the writes in lines 11190 and 11191 write to my variable space, and not to the stack. That results in the overwriting of my variable.
As I said, if needed, I can send the project directly to hi-tech.
I checked the code from version 9.60. Wow, the 9.61 code is much improved. Still, for me, using 9.61 results an increase of a few percentage of code space. And, at the percentage I'm at right now, I need as much reduction as possible. Also, since 9.60 doesn't generate similar code, I guess that means that I need to hunt down my 2nd outstanding bug. :-P
Also, with 9.60, I did see a similar behavior to the bug that I have using 9.61. In my case, every second, I read the I2C devices and send values to my debug console. What I see is "incorrect" values being reported. But, if I send out the the values in my control loop (and kill my response loop rate), the values are correct. I don't think I have a version of that code saved.
FWIW: The same code using 9.60
Code:
10629 line 235
10630 ;temperature_sensor_routines.c: 234: else {
10631 ;temperature_sensor_routines.c: 235: temperture_12bits_uint = (unsigned int) rx_I2C_buffer[0] << 8;
10632 3D4F 62 D0 05 mov reg[CUR_PP],5
10633 3D52 51 38 mov a,[0+(_rx_I2C_buffer^0x500)]
10634 3D54 62 D0 00 mov reg[CUR_PP],0
10635 3D57 53 30 mov [??_scan_temperture_sensor_devices+6+0+1],a
10636 3D59 55 2F 00 mov [??_scan_temperture_sensor_devices+6+0],0
10637 3D5C 50 08 mov a,08h
10638 3D5E u1344:
10639 3D5E 65 30 asl [??_scan_temperture_sensor_devices+6+1]
10640 3D60 6B 2F rlc [??_scan_temperture_sensor_devices+6+0]
10641 3D62 78 dec a
10642 3D63 BFFA jnz u1344
10643 3D65 51 30 mov a,[??_scan_temperture_sensor_devices+6+1]
10644 3D67 62 D0 05 mov reg[CUR_PP],5
10645 3D6A 53 B3 mov [1+(_temperture_12bits_uint^0x500)],a
10646 3D6C 62 D0 00 mov reg[CUR_PP],0
10647 3D6F 51 2F mov a,[??_scan_temperture_sensor_devices+6+0]
10648 3D71 62 D0 05 mov reg[CUR_PP],5
10649 3D74 53 B2 mov [0+(_temperture_12bits_uint^0x500)],a
10650 line 236
Code:
Thanks in advance!
Joe
|
IceCube
Tester - PRO for PSoC
Reged: Jun 27 2007
Posts: 86
Loc: The Netherlands
|
|
Hi,
I experience the same issue too. Sometimes variables get overwritten due a bank switching problem.
I am sorry I have no clear example, I can only show a (rather large) project where the bug occurs. I guess the same problem occurs here: http://www.htsoft.com/forum/all/showflat.php/Cat/0/Number/60232/an/0/page/0#Post60232
where it is a bank switching problem too.
Sometimes forcing a variable to another bank will help (using the "@" statement). Also adding --reentrant to the compiler options can provisional solve this.
@clyde: please let me know if sending the project can help.
Regards, Rolf 
|
clyde
HI-TECH team member
Reged: Oct 16 2003
Posts: 633
|
|
Joe, please send the project to support@htsoft.com. Also note that build 2249 is the latest one that has been posted here.
Clyde
|
mustang
stranger
Reged: Oct 04 2007
Posts: 19
Loc: Greater Boston, MA
|
|
Quote:
Joe, please send the project to [Email]support@htsoft.com.[/Email] Also note that build 2249 is the latest one that has been posted here.
Clyde
Clyde,
Thanks! I zipped up the version that I tested last night and sent that to the support email address.
I do most of my work from home. So, I sent it from my home email. That domain is usa.net. The user name will show up as Joe Last_Name. That's the same name the product is registered under.
I just downloaded the latest version. I checked the listing. That bug is still there. I don't see "2249" anywhere in the compiler message or the output files that I looked at. Here is the screen output of the compiler I just downloaded.
Code:
Linking..
HI-TECH C COMPILER (Cypress PSOC) Pro V9.61
Copyright (C) 1984-2008 HI-TECH SOFTWARE
Serial number: removed_by_joe :-)
Memory Summary:
Program space used 79FEh ( 31230) of 8000h bytes ( 95.3%)
Data space used 4AEh ( 1198) of 800h bytes ( 58.5%)
Comparative memory usage (excludes absolute areas and stack variables)
ROM used: 30762 bytes
RAM used: 1080 bytes
ballast_proto1 - 0 error(s) 0 warning(s) 02:41:46
Thanks for the help!
Joe
|
ga_ramirez
stranger
Reged: Jul 03 2008
Posts: 1
|
|
There's actually a real problem with this on the compiler. I have done a little project myself, that uses the UART and found that, when my receive buffer array is smaller than a total page of RAM, it fails when I'm trying to point to it via another pointer...
Sounds a little tricky, but here's the example:
1- Code generated when I use the pointers and the size of the array is smaller than a entire RAM page (in this case, 100 bytes):
----------------------------------------------------------
8567 ;serialcomm.c: 49: UART_1_TX_BUFFER_REG = fullpack[fullpack_index];
8568 7B64 70 CF and f, 0xCF ;select user reg space
8569 7B66 62 D0 00 mov reg[CUR_PP],0
8570 7B69 51 39 mov a,[0+((_fullpack_index)^0x0)]
8571 7B6B 02 31 add a,[1+((_fullpack)^0x0)]
8572 7B6D 5C mov x,a
8573 7B6E 51 30 mov a,[0+((_fullpack)^0x0)]
8574
8575 7B70 60 D3 mov reg[0xd3],a
8576 7B72 52 00 mov a,[x+0]
8577 7B74 60 29 mov reg[(41)],a
8578 line 50
----------------------------------------------------------
2- Code generated when I use the pointers and the size of the array is exactly a entire RAM page (in this case, 256 bytes):
----------------------------------------------------------
9123 ;serialcomm.c: 49: UART_1_TX_BUFFER_REG = fullpack[fullpack_index];
9124 7AF2 70 CF and f, 0xCF ;select user reg space
9125 7AF4 71 80 or f, 0x80 ;select multiple RAM page mode
9126 7AF6 62 D0 02 mov reg[CUR_PP],2
9127 7AF9 51 2A mov a,[0+((_fullpack)^0x200)]
9128 7AFB 58 2B mov x,[1+((_fullpack)^0x200)]
9129 7AFD 4B swap a,x
9130 7AFE 02 32 add a,[0+((_fullpack_index)^0x200)]
9131 7B00 4B swap a,x
9132 7B01 60 D3 mov reg[0xd3],a
9133 7B03 52 00 mov a,[x+0]
9134 7B05 60 29 mov reg[(41)],a
9135 line 50
----------------------------------------------------------
3- Code generated when I don't use the pointers, in this case it doesn't matter the size of the buffer array:
----------------------------------------------------------
8926 ;serialcomm.c: 55: UART_1_TX_BUFFER_REG = buff_tx[fullpack_index];
8927 7AFE 70 CF and f, 0xCF ;select user reg space
8928 7B00 71 80 or f, 0x80 ;select multiple RAM page mode
8929 7B02 62 D0 01 mov reg[CUR_PP],1
8930 7B05 51 A5 mov a,[0+((_fullpack_index)^0x100)]
8931 7B07 01 00 add a,<((8000h+_buff_tx))
8932 7B09 5C mov x,a
8933 7B0A 50 82 mov a,>((8000h+_buff_tx))
8934 7B0C 60 D3 mov reg[0xd3],a
8935 7B0E 52 00 mov a,[x+0]
8936 7B10 60 29 mov reg[(41)],a
8937 line 56
----------------------------------------------------------
It is clear that there is an error when it comes to pointers handling, in the first case (array < RAM page) the compiler doesn't generate the "or F, 0x80" code to allow the pointer to go to another page. There is one more thing to make clear, this instruction sets in a interrupt handler, although the pointers asignation it is made in a function before the interrupt handling, maybe this problem won't occur if all the code where to run without interrupts.
Would you please take this in count when it comes the next release of the compiler? Thanks!
PD: I'm using the HI-TECH C COMPILER (Cypress PSOC) Lite V9.61
|
clyde
HI-TECH team member
Reged: Oct 16 2003
Posts: 633
|
|
Thank you for pointing this out. It was an issue only because the code was inside an interrupt routine (the chip resets the page mode on entry to the ISR).
A fix has been committed to the compiler, and will be in the next update.
Clyde
|
|
Previous
Index
Next
Threaded
Edit
Reply
Quote
