• State Verified Answer
  • Replies 14 replies
  • Subscribers 65 subscribers
  • Views 447 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 320552
Options

I2S in NRF9161

fastfox

Hi. I am working on upgrading an old project made for NRF9160 to NRF9161. a Requirement that seems to require upgrading Zephyr/NRF SDK and this 10000 lines of application code too. Now I got stuck with I2S. It looks like a lots of stuff have changed since I originally got this working  https://devzone.nordicsemi.com/f/nordic-q-a/60256/i2s-on-nrf9160

What I would like to know that is there now any samples available that would show how I2S should be properly used? Could not find any. Apparently nowadays you could use it with zephyr APIs also, but doing that solely based on documentation does not sound very appealing. For the minimun code changes I would probably prefer to use NRFX APIs directly as before. For now, after modifying the API calls to compile with new API all I get is a crash when calling nrfx_i2s_init. So probably some magical definitions from somewhere in the SDK are missing again.

Parents
  • 0 in reply to Michal

    I finally got a debugger working at least somehow. It shows that it crashes to bus fault as soon as the NRF driver touches MODE at 0x40028504. To me this seems like exactly the correct address to set the mode. Any ideas what might cause this?

    Screenshot just before the last function call shows that config and pointer to peripheral should be ok:

    Screeshot just before the crash shows that everything should still be ok:

    Not sure how trustworthy the data here is as it looks like almost all the flags are on. But a bus fault anyway:

  • 0 in reply to fastfox

    Ok. Finally back in debugging this puppy. I tried to confirm my theory about secure/non-secure problem by looking at how SPU is configured. This is a memory dump from what I believe is the SPU peripheral configuration memory area

    SPU peripheral permissions @50003800
50003800 12 00 00 80 00 00 00 00 11 00 00 80 11 00 00 80
50003810 02 00 00 80 02 00 00 80 11 00 00 80 12 00 00 80
50003820 0A 00 00 80 0A 00 00 80 0A 00 00 80 0A 00 00 80
50003830 00 00 00 00 11 00 00 80 0A 00 00 80 02 00 00 80
50003840 02 00 00 80 02 00 00 80 00 00 00 00 00 00 00 00
50003850 02 00 00 80 02 00 00 80 00 00 00 00 03 00 00 80
50003860 02 00 00 80 00 00 00 00 00 00 00 00 02 00 00 80
50003870 02 00 00 80 02 00 00 80 02 00 00 80 02 00 00 80
50003880 02 00 00 80 0A 00 00 80 0A 00 00 80 0A 00 00 80
50003890 0A 00 00 80 00 00 00 00 3A 00 00 80 00 00 00 00
500038A0 3A 00 00 80 00 00 00 00 02 00 00 80 00 00 00 00
500038B0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

    I2S ID == 40 == 0x28
    So I suppose it is found from this line

    50003820 0A 00 00 80 0A 00 00 80 0A 00 00 80 0A 00 00 80 00 00

    And if I try to decode that

    0A 00 00 80
00001010 00000000 00000000 10000000
Swap
10000000 00000000 00000000 00001010
F == 1 == Peripheral present
A == 10 == 2 == User selectable
B == 10 == 2 == DMA has a separate attribute
C == 0 == Non secure
D == 0 == DMA transfer is non-secure
E == 0 == Unlocked

    So I2S is configured as non-secure just as it should be. I suppose there goes that theory then. Now I again have no idea why do I get that bus fault. But I just need to keep digging

  • +1 in reply to fastfox

    Hello,

    Please check if your platform/ext/target/nordic_nrf/common/core/target_cfg.c file includes this commit: https://github.com/nrfconnect/sdk-trusted-firmware-m/commit/f2a462080edc42818003d052c57d777954220145. There was an issue in previous versions of the SDK that the I2S peripheral did not get configured as non-secure due to inconsistent naming between nRFx chip variants. 

    With TF-M, peripherals will generally default to non-secure unless specified otherwise through the CONFIG_NRF_<peripheral_name>_SECURE symbols. Note: in SDK v2.6.0, the CONFIG_NRF_UARTE1_SECURE is enabled by default for debug logging. This means that the following peripherals will not be accessible to the NS application:

    fastfox said:
    And if I try to decode that

    I recommend using the peripheral viewer in the VS code or Segger Ozone debugger to view the register configurations so you don't have to decode the memory dump by hand.

    Best regards,

    Vidar

  • 0 in reply to Vidar Berg

    Aww yeah, it works. I was using 2.5.0 and now updated to 2.6.1 and no problems with I2S anymore. Unfortunately one I2C device now crashes the whole thing that had no problem in 2.5.0, but that is another story.

    Thanks for your help!

    ps. I didn't know that ozone can decode NRF register configurations. I need to try that.

  • 0 in reply to fastfox
    fastfox said:
    Unfortunately one I2C device now crashes the whole thing that had no problem in 2.5.0, but that is another story.

    Are you using TWIM1 by any chance? In that case, disabling UARTE1 in TF-M should fix the problem.

    You can disable UARTE1 and logging in TF-M by adding the following lines to your prj.conf file:

    CONFIG_TFM_SECURE_UART=n
    CONFIG_TFM_LOG_LEVEL_SILENCE=y
  • 0 in reply to Vidar Berg

    I am using that. I need to study this a bit before any conclusions. There are something like 6 I2C devices on that bus. Some use drivers from zephyr and some custom drivers outside of zephyr. But for some reason enabling CONFIG_LIS2DH  now gives hard faults. Problem could be anything really. I'll open another question if I can't sort it out by myself.

    • Reply
    • 0 in reply to Vidar Berg

      I am using that. I need to study this a bit before any conclusions. There are something like 6 I2C devices on that bus. Some use drivers from zephyr and some custom drivers outside of zephyr. But for some reason enabling CONFIG_LIS2DH  now gives hard faults. Problem could be anything really. I'll open another question if I can't sort it out by myself.

    Children
    No Data
    Related