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, My code has a problem with I2C. after study, I found it related to link sequence. It include 2 modules, say Module1 and Module2. If I add some dummy code in Module1 to make Module1 size is bigger than Module2, it works correctly. Then I check the "map" file and found Module1 linking location is before Module2. On the contrary, If I add some dummy code to Module2 to make Module2 size is bigger than Module1, it works incorrectly. The total code size is same as case 1, the only difference is that in the "map" file Module2 code location is before Module1. Anybody has any idea? Thanks.
The size difference almost certainly isn't the real reason for this problem. The order of the two modules in the output code is a lot more likely to be the root cause. OTOH, correctly written code shouldn't depend on placement in memory. Are you sure you're not getting any other warning messages from the linker? And what is that "problem with I2C", anyway? My crystal ball's in for maintenance, so you'll have to explain more about the actual symptoms you see.
Hi, Thank you for your reply. The problem is that I write a block of data and its chksum to EEPROM(24C16) through I2C, when power up next time, it checks the chksum and report a mismatch. I read (still through I2C) the data and compare, I found that a few bytes (including the chksum byte) are different from the correct one. I'm not sure these incorrect bytes are due to writing or reading. It doesn't show any error/warning message during linking/locating. Thank you again.
Do you have a pointer that's overwriting the wrong place in memory, or pointing to the wrong memory type? Or perhaps an array index out of bounds? Changing the size or order of the code might move the location of some segments. And you might only see the problem when the linker assignments are in a certain configuration, whereas in the other configuration you've still got a problem, but one which hasn't produced any symptoms (yet). Are the blocks of data you are writing via I2C code, or just some other sort of data? If it's "just data", I'd think it even more likely that the linker isn't really responsible.
Thank you for your reply. Below is copied from ".map" file, it is the only difference between correct case and NG case: Correct case: FE052EH FE0A58H 00052BH BYTE INSEG ECODE ?PR?EEROM FE0A59H FE0F74H 00051CH BYTE INSEG ECODE ?PR?I2CMOD NG case: FE052EH FE0A51H 000524H BYTE INSEG ECODE ?PR?I2CMOD FE0A52H FE0F74H 000523H BYTE INSEG ECODE ?PR?EEROM In both correct case and NG case, these 2 modules are still with same segment. All other code/data are remain same location. Both modules have a few sub-functions. Most functions of EEROM module calls functions in I2CMOD module. The firmware writes hundreds of bytes to EEPROM through I2C, only a few bytes are not correct in the NG case. Currently in our project I always try to make EEROM module size to be bigger than I2CMOD module, but I want to know the actual reason so we can prevent the problem comes out next time. I hope I can get some idea from you. Thank you again.
Below is copied from ".map" file, it is the only difference between correct case and NG case: I find that a bit hard to believe, unless you've turned off almost all optional contents of map files, including, most importantly, the lists of publics. See the "listing" tab of the project options in uV2 for what those optional parts are. Turn them on, and compare the two map files again. I still hold that the real reason for this is not the order of modules, but a straightforward bug in one of them, which just happens not be triggered if the modules are in the working order. Tracking down that bug may be very hard, though. Even more so if you can't reproduce it in the simulator, but only on actual hardware or an emulator.