Issue running TWI/SPI on nRF52832, works with Kiel but not GCC

[Jai]

Hi,

Just curious to know if anyone else had this issue and how they solved it.

My colleagues and I are working on code based on the Nordic Uart Service, in SDK13.1.0 with SD132v4.0.2 on an nRF52832 chip. For better context, colleagues develop using Kiel on Windows, where as I am developing on a Mac (NetBeans + GCC setup, GNU_VERSION = 6.3.1).

Our test project interfaces with sensors via TWI and SPI and sends data over BLE. When programmed through kiel, the device works fine (i.e. can set up interfaces, collect data, connect and send data etc.).

The same project when downloaded into my environment, can compile, build and flash code just fine. Except the following:

• TWI init() works fine.
• on attempting to initialize the first sensor and writing to it over TWI, the twi handler never gets called, and hence hangs. (e.g. nrf_drv_twi_tx() returns NRF_SUCCESS)

Similar behavior is also seen with the SPI.

I know my development environment works fine when I have to program a PCA10040 dev kit, with code from the example projects for testing. I also have a pretty good understanding of setting up the Makefile and adjusting the RAM allocations through the .ld file. sdk_config.h also has the necessary flags enabled for running the interfaces (else they wouldn't work when programmed through Kiel either). I am confused as to why a project would compile and run fine through Kiel, but will not run the same through GCC.

I have also tried flashing the twi_scanner project to a devkit, without the soft device, which works fine too.

I am guessing that I may be missing something else in my development setup, but it just does not seem obvious to me. I would be glad if some one has found the solution to this before!

Thanks, Jai

[Nguyen Hoan Hoang]

There are a few bugs in the .ld for GCC. The new stuffs with Section after the FLASH & RAM setting. Look for > RAM and replace it with '> RAM AT > FLASH'. This affects project using Softdevice. That was one of the problem I found since SDK12.

[Jai]

Thanks for your response @Nguyen. I am not sure I understand what that code changes, but I still seem to see the same behavior.

But we noticed something else that may be the root cause - After programming (soft device + application) from my system (Mac / NetBeans / GCC for clarity) and moving it to nRFGo Studio on Windows, the software showed that there was no Softdevice in the specified region.

Could it be that the nrfjprog command in the makefile needs to explicitly mention the start address for loading the soft device and application code?

For reference, this is what our memory config looks like in the linker file

MEMORY
{
      FLASH (rx) : ORIGIN = 0x1f000, LENGTH = 0x54000
      RAM (rwx) :  ORIGIN = 0x20005f40, LENGTH = 0xa0c0
}

If the memory regions are off, then the interrupt callbacks end up in the wrong space?

[Jai]

To further clarify, I am flashing and setting the soft device in the makefile commands.

`.PHONY: $(TARGETS) default all clean help flash_softdevice flash

# Default target - first one defined
default: nrf52832_xxaa

# Print all targets that can be built
help:
	@echo following targets are available:
	@echo 	nrf52832_xxaa

TEMPLATE_PATH := <path>

include $(TEMPLATE_PATH)/Makefile.common

$(foreach target, $(TARGETS), $(call define_target, $(target)))

# Flash the program
flash: $(OUTPUT_DIRECTORY)/nrf52832_xxaa.hex
	@echo Flashing: $<
	nrfjprog --program $< -f nrf52 --sectorerase --verify
	nrfjprog --reset -f nrf52

# Flash softdevice
flash_softdevice:
	@echo Flashing: s132_nrf52_4.0.2_softdevice.hex
	nrfjprog --program $(SDK_ROOT)/components/softdevice/s132/hex/s132_nrf52_4.0.2_softdevice.hex -f nrf52 --chiperase --verify
	nrfjprog --reset -f nrf52

erase:
	nrfjprog --eraseall -f nrf52`

[Nguyen Hoan Hoang]

The flash origin must be set to the correct address for it to work. Softdevice must be flashed first. As for the RAM thing in the ld. It is to ensure that the initialized global are kept. If you don't do that, it may only work when debugging but after a power cycle, your app won't work.

[Jai]

I suspect my issue may be something like that, although I don't know if I need to explicitly mention the addresses for flashing. I found this post which talks about the various code region registers, but I am unsure of how to work them into my linker file.

I have yet to try to use the jlinkexe method for flashing and explicitly setting the memory location. That may the solution...