This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM2634-Q1: How can AM2634 peripheral avoid multi-core write conflict?

Part Number: AM2634-Q1

Hi Champs,

 

If two cores operate the same peripheral at the same time, how can we avoid the conflict?

For example, we can set the GPIO output by using R5FSS0-CORE0 and R5FSS0-CORE1 to modify register respectively, and both can successfully set the GPIO. But if these two settings occur at the same time, what will happen? I don't know of any way to avoid this conflict in AM263x. I checked in TRM and found spinlocks, but this method can only use in limited cases, customer have high requirements for real-time performance, and spinlock does not seem to be suitable for them. So I'm wondering if there are any other suggestions for this?

By the way, we only have one spinlock demo in SDK(ipc_spinlock_sharedmem), is it right? Thanks!

Best Regards,

Julia

  • Hi Julia,

    For example, we can set the GPIO output by using R5FSS0-CORE0 and R5FSS0-CORE1 to modify register respectively, and both can successfully set the GPIO.

    The Am263x GPIO works in a different way, every pin has 4 different Base addresses present for each core to access the GPIO individually for real-time purposes. 

    However I understand your requirement of handling the resource management through spinlocks. We have seen similar request earlier and I have seen that the timings mentioned in the datasheet are not entirely correct. Customer can use the spinlocks and hold the resource for as long as they want. 

    By the way, we only have one spinlock demo in SDK(ipc_spinlock_sharedmem), is it right? Thanks!

    Yes, there is a spinlock SDK demo code which can be used.

    Thanks