TWI hard faulting

RE: TWI hard faulting

Jørgen Holmefjord — Fri, 03 Mar 2023 13:13:43 GMT

[quote user="kclamb2015@gmail.com"]

cool example. love the concept but it seems to be just incrementing and counting from 1 to 127. seems to be a similar problem to this guy;

twi scanner showing random address

[/quote]

Not sure why that would happen. Have you checked the TWI pins with a logic analyzer? Is one of the pins tied to GND/VDD?

[quote user="kclamb2015@gmail.com"]I'm wondering if it's because we only have 10k pullups..? Is there a way to enable the internal pullups on the sda/scl lines to help this out?[/quote]

The internal pull resistors should be enabled by default by the TWI driver. You should normally not need to add external pull resistors.

[quote user="kclamb2015@gmail.com"]Also when we start implementing this into our design, is it in your opinion better to just use the twi manager?[/quote]

That depends on your application, and what you will be interfacing. TWI manager is a higher-level library on top of the TWI drivers to easily allow you to change the configuration of the TWI peripheral between transfers, or to schedule more transfers to different devices. If your TWI slaves all support the same configuration, the driver will normally work fine as well.

RE: TWI hard faulting

kclamb2015@gmail.com — Thu, 02 Mar 2023 20:47:12 GMT

cool example. love the concept but it seems to be just incrementing and counting from 1 to 127. seems to be a similar problem to this guy;

twi scanner showing random address

I'm wondering if it's because we only have 10k pullups..? Is there a way to enable the internal pullups on the sda/scl lines to help this out?

Also when we start implementing this into our design, is it in your opinion better to just use the twi manager?

btw thanks again for all the help, really appreciate it Jørgen!

RE: TWI hard faulting

Jørgen Holmefjord — Thu, 02 Mar 2023 12:01:28 GMT

You should use the 7-bit address, see that the ADDRESS register for TWIM is only 7 bits.

If there is no slave on the bus responding to the address, you should receive an address NACK error.

Note that you can also use the TWI_scanner example to detect the address of connected slave devices.

RE: TWI hard faulting

kclamb2015@gmail.com — Wed, 01 Mar 2023 23:28:09 GMT

Thanks, I think that and some cleanup did the trick. I'm getting some data back but it looks bogus.

Should I be using the 7-bit slave address 0x18 or the 8 bit address 0x30?

RE: TWI hard faulting

Jørgen Holmefjord — Wed, 22 Feb 2023 16:26:19 GMT

The hardfault seems to be caused by modifications in the file "salt_lick_firmware\modules\nrfx\mdk\nrf52810_peripherals.h". Reverting this file back to the original from nRF5 SDK v17.1.0 seems to fix the issue.

Setting TWIM_COUNT to 0 will create an empty array of m_handlers in nrf_drv_twi.c, which makes the TWI interrupt handler trying to call an invalid address. The MDK files should normally not be modified, as this can cause issues like this.

RE: TWI hard faulting

kclamb2015@gmail.com — Thu, 16 Feb 2023 16:27:39 GMT

devzone.nordicsemi.com/.../salt_5F00_lick_5F00_firmware.zip

The code *hopefully* initializes it in twi_init() is called in main. I didn't know that static variables shouldn't be accessed by multiple files. there's probably other things being done wrong here, so we appreciate you looking at it!

RE: TWI hard faulting

Jørgen Holmefjord — Thu, 16 Feb 2023 08:25:04 GMT

[quote user="kclamb2015@gmail.com"]2) we've tried several methods, i'm currently down to a simple example to try to get something working and hoping to built from there-this is currently called in main after are setup;[/quote]

It looks to me like you in this example are calling nrf_drv_twi_rx, without first initializing the TWI driver, is that correct?

Since you have declared m_twi as static in a header file, you should not access it from multiple .c files (e.g. main.c and salt_lick_accel.c), as each file will have its own copy of the object. This means that if you initialize m_twi using a function in salt_lick_accel.c, the m_twi object in main.c will still be uninitialized.

If you can upload a .zip file of your project here, that would make it easier for us to reproduce/debug the issue.

Best regards,
Jørgen

RE: TWI hard faulting

kclamb2015@gmail.com — Wed, 15 Feb 2023 21:55:55 GMT

Hi Jørgen, thank you for taking the time to look into this.

1) it's defined globally at the top of one of our .h files;

which is included at the bottom of our main includes section;

2) we've tried several methods, i'm currently down to a simple example to try to get something working and hoping to built from there-this is currently called in main after are setup;

3) S112, i think we originally copied this project from the PCA10040e S112 blinky example

4) nRF5_SDK_17.1.0_ddde560

we have a git repo if that helps.

RE: TWI hard faulting

Jørgen Holmefjord — Wed, 15 Feb 2023 09:24:06 GMT

Hi,

How is m_twi defined in your application?

Are you triggering the TX/RX operations from main or interrupt context?

Do you use a SoftDevice in your application?

Which SDK version are you using?

Best regards,
Jørgen