How does adding data to a segment in flash cause the program to crash?

Question

I have a built-in real-time application with a main loop running at 10 kHz. It runs on a TI TMS320C configured to boot from flash. I recently added an initialized array to the source file, and suddenly the time is running out (too complicated to explain well - essentially, writing to the serial port no longer completes on time.)

Something about this puzzled me:

• I do not get access to new data by simply declaring an initialized array.
• It depends on the size - the problem only occurs if the array is> 40 words.
• I know that I do not overfill any data segments on the link map.
• There is no data caching, therefore, it is not associated with a cache integrity violation.

Any ideas on how to simply increase the size of the .cinit segment in flash can affect the time of your code?

Additional Information:
I thought that maybe the code has moved, but it is perfectly separated from the data. I checked on the memory card that all segments of the code have the same addresses before and after the error. I also confirmed that none of the segments are full. The only addresses that change on the map are the part in the .cinit section. This section contains data values ​​used to initialize variables in ram (like my array). It should not appear after calling main ().

Answer 1

My suspicions indicate a change in alignment between your data / code and the main media / memory. Adding to your data will change the location of the memory in your heap (depending on the memory model) and may place your code across the page border on a flash device, causing a delay that was not there before.

Answer 2

Perhaps a new statically allocated array pushes existing data into slower memory areas, making access to this data slower?

Answer 3

Does the problem repeat if the array is the last in its address space block? If not, look at your map, try moving the array declaration so that one after another the things placed after it are shuffled in front of it. This way you can pinpoint the corresponding object and get started, why its movement causes a delay.

Answer 4

I would take the risk myself and argue that you do not have a performance problem, but rather some kind of memory damage, which is a symptom of a performance problem. Adding an array to an executable file by changing the image in memory. Therefore, I assume that you have a memory corruption that is mostly harmless (e.g. overwriting an unused portion of memory) and switching memory more than 40 bytes because memory corruption poses a big problem. Which question is real.

Answer 5

After more than a day, looking at the tracks and the generated assembly, I think I understood this. The root cause problem turned out to be a design issue that only crashed if the ISR that started recording the serial port encountered a higher priority. It immediately became clear that you only need to add a few additional instructions in one cycle in order to cause conflicts between two interrupts.

So, the question arises: how to store, but not receive additional data in flash memory, cause additional instructions to execute?

The answer seems to be related to, but not quite the same as the suggestions of Frosty and Frederico. The new array moves some existing variables, but not across page borders or to slower regions (on this board, access time should be the same for all regions). But it changes the offsets of some commonly used structures, which forces the optimizer to issue slightly different sequences of commands to access them. One data alignment can stop the pipeline of one cycle, and the other does not. And these few instructions have shifted the synchronization enough to identify the underlying problem.

Answer 6

Can initialization overwrite another neighboring piece of code? Are there any structures or variables that use an array that are now larger and can call stackoverflow?

Answer 7

There may be a bank or page conflict. Perhaps you have two procedures that are called quite often (interrupt handlers or so) that were on the same page and now divided into two pages.