i.MX8MM A53 and M4 resource sharing

[gradimir_lj]

Hi,

We have an application with one part executed under Linux and the other under FreeRTOS on M4 controller. The two part communicate with each other over RPMsg and everything works as expected. In the new hardware release we added diode array based on SK6812MINI RGB leds. Our idea was to implement bit banging on M4 side to control the color and led intensity but we encountered a problem when implemented this. The duration of impulses that are recognized either as bits with value 1 or 0 are couple of hundred of nanoseconds. The GPIO port with leds is controlled only from M4 microcontroller and there are some dedicated pins to some peripherals on the same GPIO port but different pins. When there is no some significant load on the system leds control works nice but once we start with transmitting messages over RPMsg we can see occasional flickering, glitches. We were able to capture full leds refresh sequence on the oscilloscope and we can see that for example the sequence start as expected, duration of impulses is as expected. And the at some point the duration of the impulses is becoming higher then expected. Interrupts are disabled during leds refreshing sequence. So we tried several tests. And the last test we performed, we removed everything from firmware, FreeRTOS, PRMSg, etc.. Just left with baremetal firmware and leds control, bitbanging on M4 side. On the Linux side we created simple application that just write some values frequently to the RAM reserved for RPMsg mailboxes using devmem and we were able to recreate a problem. So my question is what can cause this kind of behavior? Can competition for internal system bus (AXI, AHB) between two masters, A53 and M4, cause this kind of behavior?

Thanks.

[Dhruvit]

Hi @gradimir_lj,

I hope you are doing well.

->The system bus manages possible conflicts when the core accesses the same resource for both an instruction read and a data read or write So If the GPIO pins used for led are used by A53 for other purposes then this can cause this kind of behavior.
A single GPIO register controls all 32 pins from this GPIO block, so accessing the same register from both sides would be a classic race condition example.

->Please make sure to check the pin connection as mentioned below.
Power supply voltage

VDD +3.5～+5.5 V
Logic input voltage VIN -0.5～VDD+0.5 V
Working temperature Topt -40~+85 ℃
Storage temperature Tstg -50~+150 ℃
ESD pressure VESD 4K V

->Please ensure the register on which one is writing some value is not overwritten by M-4 proc.

Thanks & Regards,
Dhruvit Vasavada

[gradimir_lj]

Hi,

Thank you for the answer. As I already mentioned in the question I do not have problem with race condition or with GPIO value overwritten by A53 or M4 core. The specific GPIO is controlled just from M4 core, A53 is not using it. Also to be more precise I do not have problem with the value written to GPIO register. What I put into the GPIO register this is propagated to the GPIO pin.

The problem is with timing, Usually the propagation time between the moment I set some value to the GPIO register until the moment I see change on GPIO pin is around 300ns. But I think when there is some higher load on the system this time jumps to 600ns for example. The interrupts on M4 are disabled. No branching in the code that can cause this.

I would like to know what can cause this kind of behavior. Is this because of sharing the same system bus between different masters like A53 and M4?

Best regards,

Gradimir.

[Dhruvit]

Hi @gradimir_lj,

Yes, One can say that The sharing of chip resources between the somewhat independent processing domains allows for the opportunity for data collisions where information stored in peripherals or memory by a process on one core is overwritten by software running on another core.

But RDC provides a semaphore-based locking mechanism to provide for temporary exclusivity while the domain software uses the peripheral.

One should refer to Section 3.2 Resource Domain Controller (RDC) of RM.
https://www.nxp.com/webapp/Download?colCode=IMX8MMRM

Thanks & Regards,
Dhruvit Vasavada

[gradimir_lj]

Ok. Imagine the situation like this. There is GPIO controlled only from M4 and RDC is properly configured so there is no way that A53 has access to this peripheral while M4 domain is using it. But Linux application running on A53 cores constantly writes and reads something from RAM memory, from non caching area. And at some point in time M4 wants to set some GPIO output value and A53 want to write something to the RAM location directly (not cached) at the same time. And in order to do this both processor domains need to require access to AXI/AHB system bus in order to do this. So here you have competition for shared resource, AXI/AHB bus. AXI/AHB bus will allow only one domain at a time to use its services. So one processor will be waiting for the bus to become free while the other is active. And there is no mechanism to prevent this.

Gradimir.

[Dhruvit]

Hi @gradimir_lj,

I hope you are doing well.

Yes, Exactly you are right because, the AHB master is an interface unit that allows user logic to initiate a data transfer on AHB, the bus master is optimized to interface with DMA and PCI bus bridge function to initiate data transfer on the AHB.

On AHB before every transaction, a master makes a request to the central arbiter, although AHB systems are multiplexed and thus have independent read & write data buses, they cannot operate in full-duplex mode, which may be a reason that while sending read-write nonstop the GPIO signal could be compromised and flickering happens.

Thanks & Regards,
Dhruvit Vasavada