We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hello, We have a product controlled by a C8051F060, which among other tasks measures the internal temperature of the MCU, and if it exceeds some rate of temperature for more than a specified time the measurement is saved to a 'internal high temperature table'.
The Same task is done in our older product, which is controlled by a C8051F020, and works as expected, with no issues, i.e. can be read and reset by a protocol command.
At The product controlled by the C8051F060 when reading this table includes unreasonable values (negative, 65535 and others), which appear also when there is no high ambient temperature what so ever.
This table is located in the data memory, as appears in the map file(L. 129): www.mediafire.com/.../file
I found it hard to troubleshoot the problem, since the task of saving high temperature functions properly at the F020 product and the task in the F060 is taken from there. It seems that the wrong data source is a result of some memory issue as stack overflowing.
I would be glad for any guidance for solving this issue. Thanks, Amitai
... use it!
Thanks, The product is synchronized by interrupts to a motor's rotation, includes communication waiting commands and measuring interrupts. It's a large code and is complex.
To start commenting lines and assigning dummy values is a long task which might change the behavior of the whole system and might also hide the source which causes the issue.
Aren't they any hints of memory for such issues? some place worth to check for wrong coding or wrong size calculation?
When looking into your map file, line 129 shows nothing more than a single byte in RAM. How did you get a value like 65535 from that "table"?
This 1 byte also doesn't make sense to me, but I now that the other units there function properly with no issues. I found nothing in documentation which can explain about this.
I've zipped up two files which are associated with the high temperature table - The declaration of the table and updating the flash:
www.mediafire.com/.../file
The table is named 'timetable' and built from the _timetable structure (saved in xdata). The structure's is:
typedef struct { unsigned long ht_time[MAX_RECORDS_No], wsp_counter; int cntrl_No; } _timetable;
.
Thanks, Amitai
Ha ha - that old chestnut: the "proven-product syndrome"
You would not be the first to come across fundamentally flawed code which appears to "work" (sic) !
About 130 products are functioning with no other issues (measurement, communication, interrupts, ADC, DAC etc.) for over 3 years. The issue of this table appeared right at the beginning of production process. I assume that if other memory was effected we would notice it.
Again, since this table is located in the beginning of the data memory so it seems that it is overloaded from somewhere else. (In the RAM existence it's somewhere in the middle, according to the map).
Now that I have files to look at, this 1 byte actually makes sense. As everything in ht_records.c goes to xdata, there's only on byte left: change_flag. This is what you're seeing in the map file.
BUT: ID_ADDRESS is defined to 0x0000 (flash_driver.c). So this seems to access your controller's vector table:
Line 48 - FLASH_PageErase (ID_ADDRESS, 1); Line 67 - pID[i] = FLASH_ByteRead (ID_ADDRESS + i, 1);
And what is this? Line 55 - FLASH_ByteWrite(i, pID[i - ID_ADDRESS], 1);
I'll confess that I don't really know the intention of the code writer, might be the this address was associated first to a different location in memory.
These functions FLASH_PageErase and update are located In the (Silabs original?) file:
Thanks