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.
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.