Hi @SploreLcp ,
For better analyzing this issue, can you please help to input some detail description about below questions:
1. The original FXIO I2S driver/example provided by S32K3 RTD driver should work. So why customer met such a problem?
2. Can you please describe detailly what customer is doing now? What's the target FXIO I2S function they want?
Besides, the I2S data will have 1 BCLK delay after I2S FSYNC signal edge according to I2S standard. So is this issue not an issue according to the standard? Can you please also comment about this point? Thanks.
Regards,
Shuailin
Hi @tonyxu & @SploreLcp ,
Please note, the I2S standard published by Philip noted that the data signal will delay 1-bit after Frame Clock signal. Which means the 1-bit shift phenomenon customer raised is certainly correct. It is not an issue.
I reviewed the issue project, found that the customer using "blocking" method to send data in the IRQ handler callback, it is highly discouraged to using this way. It would block interrupt for a long time and may cause damage result. I have already found extra no-mean clock/data appended on the end of the transferring.
Please using "non-blocking" method instead in the callback function like below:
After tweaking this send data method, the signal seems alright now:
FYI.
Regards,
Shuailin
Hi, Shuailin,
Due to customer changed hardware design. Test validation is being done on the new version PCBA. Later the test results, test project and waveform diagrams will be updated to your side individually via shared folder.
Thanks!
Hi @tonyxu ,
After checking your attached project, I found that the DMAMUX configuration was lost, which caused FXIO I2S data transferring not work as expectation.
In S32K3 RTD RTM 3.0.0, the DMAMUX configuration is located in "Rm" component, a HLD component which we need to add from "MCAL" content. The HLD and LLD component can be mixed-use in S32DS:
Besides, after configurate the DMAMUX in "Rm" component, we need to involve the corresponding header file and initiate it:
Another found is that customer used wrong DMA channels Interrupt configuration which was not the same as .mex configured. Tweaked it as below:
Actually, we'd like to recommend customer to use "IntCtrl_Ip" component in .mex to configure all the interrupts instead of manually invoke IntCtrl_Ip APIs in code, which would be easier of use.
After those changes, we can see the demo works well:
The attachment is the tweaked project, please kindly check.
FYI.
Regards,
Shuailin Li