• State Verified Answer
  • Replies 14 replies
  • Subscribers 65 subscribers
  • Views 468 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.

  • 0 in reply to Michal

    Yes I did CONFIG_I2S=y

    You don't have any idea how to make sure that I2S really is insecure? I need to try to find some documentation for this once I again get more urgent matters away from my desk.

    • First just try it
    • Then debug it
    • If nothing else helps, read the manual

    Slight smile

  • 0 in reply to fastfox

    I will have to research more into the secure/insecure peripherals and ask around my colleagues, as I am not an expert on TF-M.

    I will get back to you.

    Best regards,

    Michal

  • 0 in reply to Michal

    Hello,

    Did you get any progress on that in the meantime by chance?

    Best regards,

    Michal

  • 0 in reply to Michal

    Noup. This is in my low priority list. But it has to be done at some point anway. I'll post here once I get back to this and figure out how to get it working.

  • 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

Related