Peripheral sharing with dual core H7

[RMcCa]

I am working with a dual core processor for the first time & am wondering if i need to use a semaphore to block one processor while the other reads a peripheral register?

In my application the M4 is being used as a slave for some concurrent processing but needs occasional access to the RNG. I could certainly use a semaphore, taken and then released by the M7 when it's accessing the RNG. Just wondering if it's necessary. Seems like it might be because the M4 reads a group of random numbers in a loop and polls the data ready bit of RNG.

​

Thanks.

[Tesla DeLorean]

Generally it will arbitrate access to specific registers. If you can localize access of a specific peripheral/registers to a specific core, then no semaphore would be needed.

But yes, if you're spinning on status to wait for availability (RXNE), or readiness, I think you need to use a semaphore to take ownership to avoid race conditions where the other core grabs data from you.

The RNG is more closely located to the M4

[TDK]

Unless you want to avoid the M7 and M4 core from potentially using the same random number, there's no need to gate access for read operations. They can access it at the same time without issue. They can write at the same time as well, but one core will overwrite whatever the other did.

[RMcCa]

Thanks. After rereading the data sheet & giving it a little more thought, i decided using a semaphore is a good idea because of the speed of random number generation and the fact that the m4 needs about 300 of them. They are read in a fairly tight loop, so polling the RNG ready bit is necessary and i could see how the other processor trying to read the RNG during this process could be a source of a nasty bug.​

[RMcCa]

I think i understand, but have one more question. I am not checking the RNG ready bit in the M7 core because it only needs to read 1 32bit number at 26khz, so without the M4 trying to read a bunch of randoms, there will always be one available.

If instead of using a semaphore i poll for the ready bit in both cores​ is the worst thing that could happen is both cores reading the same random number or is there still a chance of a race condition?.

Thanks.​

[Tesla DeLorean]

Haven't reviewed the hardware interaction in this context, but yes, worst case I suspect you'll read the same value or some intermediate/indeterminant value as the read causes a new value to be computed/generated.

As you're blind reading the thing anyway probably not a big issue. Would suggest you experiment generating a couple of parallel streams of data, and determine if they meet the "randomness" requirements for your specific application/use-case.

[TDK]

The worst thing that can happen is you will deplete the 4 32-bit values available, and one core will read 0 as its random number. There is the possibility of the data ready (DRDY) changing (and thus data not being ready) between when you poll the DRDY bit and when you read the DR register if the other core reads it first.

I tried very hard to get both cores to read the DR register at the same time and was never able to get them to read the same value. They either returned a unique value or 0. So upon further evaluation, I don't think the duplicate number scenario is likely. Checking if DR=0 after read would solve this problem, in which case you wouldn't need to poll DRDY either. Just my experience.