SPI failure in case of modifications to unrelared code segment

RE: SPI failure in case of modifications to unrelared code segment

bjorn-spockeli — Wed, 04 Sep 2019 08:29:22 GMT

t_prachar: Great! The CPU does not have to touch the buffers the bug may occur when the CPU is writing or reading to the same RAM block as where the SPI3 DMA buffers at the same time as the SPIM is fetching data from RAM.

[quote user="t_prachar"] Does the "RAM block" mean "RAM section" as laid out in section 4.2.1 of the nRF52840 datasheet? Or "RAM AHB slave"?[/quote]

By different RAM Block we mean different RAM AHB Slave.

Best regards

Bjørn

RE: SPI failure in case of modifications to unrelared code segment

t_prachar — Tue, 03 Sep 2019 21:31:02 GMT

Enabling that workaround fixes the problem. Thanks!

We did not consider this workaround required because the the transmit and receive buffers are not touched by the CPU when the SPI transfer is in progress. Perhaps the ambiguity is in what is meant by "same RAM block" in the errata description. Perhaps you can describe in more detail what is meant by this phrase in this context since it is apparently a block that is larger than the buffer used by the SPI peripheral. Does the "RAM block" mean "RAM section" as laid out in section 4.2.1 of the nRF52840 datasheet? Or "RAM AHB slave"?

RE: SPI failure in case of modifications to unrelared code segment

bjorn-spockeli — Tue, 03 Sep 2019 06:54:21 GMT

t_pracharIs NRFX_SPIM3_NRF52840_ANOMALY_198_WORKAROUND_ENABLED when you see the issue?

RE: SPI failure in case of modifications to unrelared code segment

t_prachar — Mon, 02 Sep 2019 20:43:37 GMT

Was there ever resolution on this issue? I see a similar issue where SPIM transfers result in invalid data intermittently. Increasing stack size made no difference, but taking out about 18KB from BSS eliminates the error. The project (gcc) isn't overly large,and RAM usage is modest. On 2KB SPIM reads, the typical failure is the entire buffer is read back as 0x00. I can repeat the read operation and it usually succeeds on the second attempt.

This is with SDK15.0 and all error codes are being checked and no return errors are noted. nrfx_spim driver on SPI instance 3 on the nRF52840. gcc version 7.3.0.

Start of .ld file (we have SD140 and the USB bootloader also loaded)

MEMORY
{
FLASH (rx) : ORIGIN = 0x26000, LENGTH = 0xda000
RAM (rwx) : ORIGIN = 0x20007000, LENGTH = 0x39000
}

Failure case:

text data bss dec hex filename
300308 1860 46588 348756 55254 _build/nrf52840_xxaa_V3.out

Success case:

text data bss dec hex filename
289332 1860 28784 319976 4e1e8 _build/nrf52840_xxaa_V3.out

RE: SPI failure in case of modifications to unrelared code segment

hmolesworth — Fri, 30 Aug 2019 21:30:54 GMT

edit: piqued++; // why do I bother ..

You may be having this issue:

"3.29 [198] SPIM: SPIM3 transmit data might be corrupted
This anomaly applies to IC Rev. Rev 2, build codes QIAA-Dx0, KAA-Dx0. It was inherited from the previous IC revision Engineering D nRF52840.
Symptoms Transmit data from SPIM3 is corrupted.
Conditions: Data accessed by CPU location in the same RAM block as where the SPIM3 TXD.PTR is pointing, and CPU does a read or write operation at the same clock cycle as the SPIM3 EasyDMA is fetching data.

Consequences Transmit data from SPIM3 is corrupted.
Workaround Reserve dedicated RAM blocks for the SPIM3 transmit buffer, not overlapping with application data used by the CPU. In addition, synchronize so that the CPU is not writing data to the transmit buffer while SPIM is transmitting data."

Changing code or moving RAM can have the unexpected side effect that the SPIM memory moves. There are some posts on this, worth a search perhaps but best to dedicate a RAM block just to SPI3. Hard to predict when a failure will occur, unless all other cpu RAM access are blocked.

NRFX_SPIM3_NRF52840_ANOMALY_198_WORKAROUND_ENABLED is worth looking at; don't know if that helps (I haven't studied it).

This spim3-sending-wrong-data-byte link might help

RE: SPI failure in case of modifications to unrelared code segment

t_prachar — Fri, 30 Aug 2019 19:47:47 GMT

This is with SDK15.0 and all error codes are being checked and no return errors are noted. nrfx_spim driver on SPI instance 3 on the nRF52840. gcc version 7.3.0.

Start of .ld file (we have SD140 and the USB bootloader also loaded)

MEMORY
{
FLASH (rx) : ORIGIN = 0x26000, LENGTH = 0xda000
RAM (rwx) : ORIGIN = 0x20007000, LENGTH = 0x39000
}

Failure case:

text data bss dec hex filename
300308 1860 46588 348756 55254 _build/nrf52840_xxaa_V3.out

Success case:

text data bss dec hex filename
289332 1860 28784 319976 4e1e8 _build/nrf52840_xxaa_V3.out

RE: SPI failure in case of modifications to unrelared code segment

t_prachar — Fri, 30 Aug 2019 18:59:14 GMT

This is with SDK15.0 and all error codes are being checked and no return errors are noted. nrfx_spim driver on SPI instance 3 on the nRF52840. gcc version 7.3.0.

Start of .ld file (we have SD140 and the USB bootloader also loaded)

MEMORY
{
FLASH (rx) : ORIGIN = 0x26000, LENGTH = 0xda000
RAM (rwx) : ORIGIN = 0x20007000, LENGTH = 0x39000
}

Failure case:

text data bss dec hex filename
300308 1860 46588 348756 55254 _build/nrf52840_xxaa_V3.out

Success case:

text data bss dec hex filename
289332 1860 28784 319976 4e1e8 _build/nrf52840_xxaa_V3.out

RE: SPI failure in case of modifications to unrelared code segment

Jawad — Thu, 22 Dec 2016 12:17:09 GMT

Hi Bjorn,

Setting the heap to 0 solved the problem but now when I enable TLS for mqtt communication I again get region RAM overflowed with stack. I have tried changing stack to 16kB with heap as 0 and also tried with various other combinations of stack and heap but the error stays the same. I think this is a separate issue therefore I posted it here. I am not using any soft device so is there any way of making TLS work by utilizing maximum available RAM?

RE: SPI failure in case of modifications to unrelared code segment

bjorn-spockeli — Tue, 20 Dec 2016 12:58:29 GMT

Happy to help :)

RE: SPI failure in case of modifications to unrelared code segment

Jawad — Tue, 20 Dec 2016 12:43:44 GMT

Hi Bjorn, Heap size was set to 8192 in the arm startup file and changing it to 0 has solved the problem for now. I can run whole functionality of my project with 8kB stack and heap as 0. Thanks for the support throughout :)

RE: SPI failure in case of modifications to unrelared code segment

bjorn-spockeli — Tue, 20 Dec 2016 10:36:05 GMT

Are you using the heap in your project? If not then you can set the heap size to zero by adding the following assembler flag.

ASMFLAGS += -D__HEAP_SIZE=0

If __HEAP_SIZEis not defined, then it will be by default set to 8192, i.e. 8kB. You should be able to increase the stack size by setting the heap size to zero.

RE: SPI failure in case of modifications to unrelared code segment

Jawad — Tue, 20 Dec 2016 10:29:34 GMT

13kB seems to be the upper limit as I start getting "region RAM overflowed with stack" from 14kB

RE: SPI failure in case of modifications to unrelared code segment

bjorn-spockeli — Tue, 20 Dec 2016 10:24:02 GMT

No problem Jawad, we're here to help. Are you able to increase the stack size even further or is 13kB the upper limit?

RE: SPI failure in case of modifications to unrelared code segment

Jawad — Tue, 20 Dec 2016 10:15:57 GMT

Hi Bjorn,

It doesn't work with the 12kB RAM but it works with 13kB but now there is another issue. In my project I am using an LED to represent different system states. When I go to 13kB, the SPI and the wifi communication starts working fine but the LED stops responding. When I comment out the previously mentioned part of code it works again. Apologies for bothering you time and again but do you have any other suggestions.

RE: SPI failure in case of modifications to unrelared code segment

bjorn-spockeli — Tue, 20 Dec 2016 09:40:38 GMT

Ok, try reducing the stack size to 12kB

ASMFLAGS += -D__STACK_SIZE=12288

RE: SPI failure in case of modifications to unrelared code segment

Jawad — Tue, 20 Dec 2016 08:57:25 GMT

Thanks Bjorn, If I add the above mentioned line to the Makefile I get the following error "region RAM overflowed with stack" during compile

Thanks

RE: SPI failure in case of modifications to unrelared code segment

bjorn-spockeli — Tue, 20 Dec 2016 08:50:38 GMT

I just wanted to check whether the initialization of the GPIO pins affected the SPI peripheral. Yes, it is possible that this is a memory issue, but I would expect the nRF52 to hardfault if you were pushing large arrays to the stack and causing stack overflow. You can try to increase the stack size, e.g. doubling it by adding the following define to the assembler flags

ASMFLAGS += -D__STACK_SIZE=16384

Other than than my only advice is to comment out all the code that causes the SPI to nor function properly and then include small sections at the time until the error occurs while keeping an eye on the stack pointer.

RE: SPI failure in case of modifications to unrelared code segment

Jawad — Mon, 19 Dec 2016 16:10:46 GMT

Hi Bjorn, I have tried with what you said and then SPI works but the issue is that the part of code I am commenting out to make SPI work does not have anything to do with the pins of SPI. Instead there are a lot of pointers and arrays are present in that part so I was wondering if it is a memory issue. Do you have any suggestion about debugging such an issue?

Thanks a lot so far

RE: SPI failure in case of modifications to unrelared code segment

bjorn-spockeli — Mon, 19 Dec 2016 13:34:49 GMT

I am assuming that you're initializing the GPIO pins somewhere in the code. Could you comment out all code associated with these pins except the initialization? Does the SPI function properly then?

RE: SPI failure in case of modifications to unrelared code segment

Jawad — Fri, 16 Dec 2016 09:54:48 GMT

Hi Bjorn, Please see my response below

RE: SPI failure in case of modifications to unrelared code segment

Jawad — Fri, 16 Dec 2016 09:43:05 GMT

Thanks for the comment Bjorn. Below are few such lines of code. They are there for the recording of signals received on gpio pins and those pins are completely different from SPI pins.

	//if transmit interrupt has triggered- toggle pins and reset timer
	if(bus_driver_pins_toggle_flag_volatile == true){
		//reset the flag which has been set in the ISR
		bus_driver_pins_toggle_flag_volatile = false;
		SEGGER_RTT_WriteString(0,"noooooooooooooooooooooooooooooooooooooooooooooooooooo\n\r\n\r\n\r\n\r\n\r\n\r");

		vBus_Pin_Toggle_Handler(); // Uses the hard coded pulse times
		//vBus_Pin_Toggle_Handler_Recorded(); // Uses the real measured pulse times
	}

	//if comparator interrupt has triggered - do time measurement
	if(bus_driver_comparator_flag_volatile == true){

		vBus_Pulse_Time_Measurment_Handler();
	}

	//if time out is detected this means the package has been received.
	if(bus_driver_time_out_flag_volatile == true){
		bus_driver_time_out_flag_volatile = false;
		vDisable_Bell_Signal_Reception();
		SEGGER_RTT_WriteString(0,"Bus package received\n\r");
		u32_bell_detected_flag = u32_Check_Bus_Package();
	}

Also here is another part of code, with same implications,controlling LEDs through pins unrelated to SPI

		   if ((led_delay_value != 0xFFFFFFFF) & (led_delay_value > 0))
				{
					led_delay_value --;
				}
				status_led_main(calling_argument_for_status_led_main);

RE: SPI failure in case of modifications to unrelared code segment

bjorn-spockeli — Fri, 16 Dec 2016 09:34:35 GMT

Hi Jawad, could you post the "unrelated" code that causes the SPI communication to fail?