So I “solved” my issue, which indeed was a cache problem. My test was simple: write some data structure on the 2nd core in a shared area, then send a message to the 1st core with the address of said structure, using the Mailbox. Then the 1st core would read data from this structure and log it. I was consistently getting bogus data. Only got good data in one case, which was probably just sheer luck due to the memory access sequence.
My guess at this point was that data written from the 2nd core would stay in its D-cache and so the 1st core would not see it. Which would imply that both cores (on the CV1800B) have separate caches. Which makes sense, although, again, it’s not clearly documented, and the architecture diagram seems to imply that the caches are shared between the 2 cores. They apparently aren’t. Are they identical in size though? Who knows. The diagram would suggest so, but the datasheet is otherwise not clear at all about it. The diagrams for the SG200x show that both cores have different caches, and that the ones for the 2nd core are smaller. For the CV1800B, it’s anyone’s guess.
Long story short, I added a “th.dcache.call” instruction after writing data in the shared area (on the 2nd core). And bam, it did solve the issue.
Now my question is, is there a different/more efficient way of dealing with this cache issue than triggering a write-back to the D-cache? Surely it must be a common problem for sharing RAM on multi-core systems with separate caches. Let me know your thoughts.