System Hardfault when calling dwt_probe()

Hi all,

I am integrating our Cortex-M33 MCU board with DM3000 EVB (DWM3000EVB - Decawave) in IAR IDE project

Our MCU signal is 1.8V while DM3000EVB uses 3.3V signal, so I add volt level shifter in between.
Currently, I got system hard fault when it calls dwt_probe().

Here is my software setup:

1- I added this to the IAR linker script to place dwt_driver APIs in flash:

define exported symbol __dw_drivers_start = 0x08001180;
define exported symbol __dw_drivers_end. = 0x08008FFFF; //512KB
define region TEXT_DW_region = mem:[from __dw_drivers_start to __dw_drivers_end];
define block DW_DRIVERS with alignment = 4 { section *.dw_drivers};
place in TEXT_DW_region {block DW_DRIVERS};

2- I link the project with libdwt_uwb_driver-m33-hfp-6.0.7.a library

3- I run read_dev_id example

4- I probe 3V3 SPI signal on the DM3000EVB side and see it outputs DEV_ID correctly when dwt_probe() calls my platform-specific readspi() function. Then I see it does not exit dwt_probe() but jumps to hardfault handler forever.

I read DW3XXX_Software_API_Guide_2p2.pdf document to see it mentions about populating “struct dwt_driver_s dw3000_driver” but I do not see such structure defined in the example code for STM32F429 Nucleo EVK or nRF52840 EVK

Should I need to populate “struct dwt_drivers”? Can you provide a example about populating that structure?

Best regards,
Ben

Can you write your own code to test your SPI layer, at least as far as reading DEV_ID? I just want to make sure that you’ve got things like the SPI mode set up right. Specifically, if you push five 0x00 bytes, you should get 0xDECA0302 back for the last four.

Spi most likely.

The second problem is that you specify the address of the end of the __dwt_driver_end symbol.

The way dwt_probe() is organized is that there is an iterator of N driver structures, so you read chip id via spi, then compare to the driver struct, if matches - use that driver.

One problem is that if spi does not read correct chip id.

Second problem is that say if we reach the final N driver struct, the dwt_probe() will keep iterate and that obviously would end to an error.

I would recommend you dump the downloaded code and check memory where drivers structs placed.

I confirmed that dwt_probe() calls our platform-specific spiread() implementation and I also probed SPI lines to see that DM3000 returns correct CHIP_ID which is 0xDECA0302.

The second problem is that you specify the address of the end of the __dwt_driver_end symbol.
Second problem is that say if we reach the final N driver struct, the dwt_probe() will keep iterate and that obviously would end to an error.
I do not understand what “driver struct” here. Do you mean “struct dwt_driver_s dw3000_driver”?
Should I need to implement such structure in the code? I do not see any reference implementation for that structure in DWM3000EVB_Release_v1.2.zip file that I downloaded on Qorvo website.

Can you explain more about driver struct and how to support it in new MCU platform?

Best regards,
Ben

Hi all,

I corrected the value for __dw_drivers_end to 0x08008FFF.
Is that the issue mentioned by Alliv by this comment?

The second problem is that you specify the address of the end of the __dwt_driver_end symbol.

Regards,
Ben

Hi all,

I can resolve the issue now.
I need to place this section at the address in flash specified by __dw_drivers_start in IAR linker script:
define exported symbol __dw_drivers_start = 0x08001180;
define exported symbol __dw_drivers_end. = 0x0800119F;
define region TEXT_DW_region = mem:[from __dw_drivers_start to __dw_drivers_end];
define block DW_DRIVERS with alignment = 4 { section .dw_drivers};
place in TEXT_DW_region { block DW_DRIVERS};

Now I can some examples fine.
Thanks for the support. I will post questions when I evaluate more DM3000 features.

Best regards,
Ben

Hi @BenFossil, thanks for the description of how-to link the ABI drivers’ library in IAR. That also shows that the EABI is a working mechanism, which is great.