AHB congestion and the potential for stalling peripherals

[dbuijsma]

We're evaluating the nrf52840 and I am looking at the SPIM peripheral. The datasheet states the following: 

"If several AHB bus masters try to access the same AHB slave at the same time, AHB bus congestion might occur. The SPIM is such an AHB master, and when congestion occurs the SPIM might have to wait for access to RAM to be granted. If the SPIM has to wait for bus access the transaction will be temporary stalled, but resume once the SPIM is granted access to the bus. See the AHB multilayer on page 48 for more information on this subject. Note that some SPIM instances do not support this stalling mechanism.

Refer to Instances on page 379 for information about what features are supported in the various instances."

So SPIM0 though SPIM2 do not support stalling, but SPIM3 does. In the memory section there's more information:

Some peripherals, for example radio, do not have a safe stalling mechanism (no internal data buffering, nor opportunity to pause incoming data). Being a low priority bus master might cause loss of data for such peripherals upon bus contention. To avoid AHB bus contention when using multiple bus masters, apply one of the following guidelines:

• As a good general rule, avoid situations where more than one bus master is accessing the same slave.
• If more than one bus master is accessing the same slave, make sure that the bus bandwidth is not exhausted.

This raised some questions:

1.) RAM memory is divided in multiple AHB-bus slaves if I interpret the diagrams correctly (figure 1 and figure 2 in the Product Spec). Does that mean that contention will NOT happen if I keep my SPIM source data in one of the RAM locations and do not access it with any other Masters? 

2.) The CPU is a AHB master as well. If the CPU were to access the RAM block where the SPIM peripheral is reading from, can contention occur? 

3.) What does "loss of data" mean? Say I am doing a large SPIM transfer and contention occurs in the middle of the xfer, are some bytes simply not sent or does the entire transfer halt? I'm trying to understand what measures I'd have to take in the code to prevent issues.

4.) Is there any way to detect contention when it occurs?

Thanks,

Dirk

[Kenneth]

Hi, 

1. Correct
2. Contention may occur, but it is quite unlikely if it is just the CPU and one SPIM. There are several clock cycles (number depends on the data rate) between RAM accesses from the SPIM – during that time the CPU has access the RAM.
3. For SPIM0-2: some bytes are not sent
   For SPIM3: it will pause the SCK until DMA access is possible again. No data is lost.
4. STALLSTAT register in the SPIM3 peripheral 

Note that SPIM0-2 only support 8 Mb/s as maximum data rate, the risk of AHB congestion quite low. However, SPIM3 can operate at up to 32 Mb/s. 

Regards,
Kenneth

[dbuijsma]

Ok, so it sounds like this could easily happen when USB, SPI 0-2 or I2C + DMA and CPU are accessing the same RAM block. Do you have any design guidelines we can use to make sure this will never happen? (aside from the obvious ;)

I do not believe I have ever encountered this with any other MCU I have worked with. The only time I have ever run into congestion was with an LPC17xx where the LCD controller/DMA and CPU were competing for bandwidth. No data loss ever occurred though. 

I am just curious: why not simply add a buffer to the peripheral like SPI3 has or add an option to halt peripheral operation instead of aborting the entire transaction (which will be a pain to take into account in the FW...)?