That was going to be my question, are you using RPC at all?
RPC also disables the cache (that's where I lifted the code from) so this is likely the problem. I tried RPC but found it slow and resource hungry.
If you are planning to use RPC then don't use post #11. If you want to remove RPC then you can use bootM4(); to, errr, boot the M4 ![]()
Deleted RPC. Still no luck. This work
SCB_InvalidateDCache_by_Addr((uint32_t*)(AHB_SRAM3_ADDR), 64);
But only from M4 to M7. The only variable I update in M7 to be used by M4 is not updated in M4.
I use this in both cores
// Use a pointer to the shared memory address
#define AHB_SRAM3_ADDR 0x30040000
//Assign memory locations for each variable
volatile int16_t* cntr = (volatile int16_t*)(AHB_SRAM3_ADDR);
volatile int16_t* SenGZ = (volatile int16_t*)(AHB_SRAM3_ADDR + 2); // 2 bytes per int16_t
volatile int16_t* SenAX = (volatile int16_t*)(AHB_SRAM3_ADDR + 4);
volatile int16_t* SenAY = (volatile int16_t*)(AHB_SRAM3_ADDR + 6);
volatile int16_t* Pot = (volatile int16_t*)(AHB_SRAM3_ADDR + 8);
volatile int16_t* Flag = (volatile int16_t*)(AHB_SRAM3_ADDR + 10);
Any ideas??
My stupidity. Used the wrong address.......
code in post #11 will disable caching for domain 3 which includes SRAM4. If you need to use SRAM3 (domain 2) then the code will need tweaking and I suspect it will disable caching for SRAM1 and SRAM2 which are also in domain 2.
I changed the address to 0x38000000 and it is working 100% now. I reactivated RPC and it still works. But when RPC is activated I2C speed falls dramatically. 430 readings per second with RPC activated and 1280 readings per second with RPC deactivated. The readings is on the I2C bus. makes no sense to me. I only use RPC for debugging in M4 to do RPC.println.....
Like I said, slow and resource hungry. I used some of the shared mem for debug messaging.
p.s. RPC is also using SRAM4 so make sure there's no overlap in addressing if you decide to stick with it.
Thank you once again. Now to get the I2C clock speed to 1Mhz ........
Been digging into this I2C frequency problem and there's a timing algorithm (i2c_get_timing) that uses the I2C input clock plus the requested frequency to calculate an actual frequency it will use.
My suspicion is that the problem stems from the fact you are using the M4 to read the sensors. Not sure how easily you could do it, but a test of your M4 code on the M7 could be illuminating.
Apologies for the late reply. Had to put in some sleep. I did try the Wire.setClock() function on both cores. No change.
P.S. Now that I am using the correct SRAM4 address the code works without the code supplied by you in post#11. Maybe the buffer is still on but gets emptied quickly because of the amount of data updated per second?
I'll see if I can free up some time to investigate further.
If you're still defining as volatile then that's probably the reason as it bypasses the cache.
Problem solved. Do the Wire.begin(). Then all other xxx.begin()'s. Then Wire.setClock() last in setup(). On the Mega, Due and ESP32 Wire.setClock() must be directly after Wire.begin(). 100000 runs at 108kHz, 400000 runs at 401kHz, 1000000 runs at 799kHz as measured on my oscilloscope.
Not a nice signal on the oscilloscope, might have to add some pullup resistors.
Hurray! Maybe it was the adafruit's own setClock() that was mucking things up.
Thank you again for your help. Hope I do not have to bother you too soon again ![]()