I've got an old project that was running on SSP 1.2.1 on a S5D9 and running sort of right. It has some sort of bug in the I2C driver that another project (on the same board) running on SSP 1.7.5 does not so I figured I'd port things to that platform and work from there.
That's where the trouble is coming in. On this platform, I'm having problems opening the I2S channel (the other project, which is also on SSP 1.7.5 has no problem doing that). I've looked at the generated code for that and find no substantial differences between them. What it's doing on this one is that it gets to the code in r_ssi.c
if (NULL != p_cfg->p_transfer_rx) { p_cfg->p_transfer_rx->p_cfg->p_info->p_src = (void *) HW_SSI_RxAddrGet(p_ctrl->p_reg); err = ssi_transfer_configure(p_cfg, p_feature, p_cfg->p_transfer_rx, SSP_SIGNAL_SSI_RXI); SSI_ERROR_RETURN((SSP_SUCCESS == err), err); }
And this has got a p_transfer_rx (I don't need to read from this thing; it's master to my audio amps) and when it gets the the ssi_transfer_configure it returns SSP_ERR_IRQ_BSP_DISABLED which is true enough. So it is in the other project that doesn't have this problem too. I don't need to read these things, just write 'em
I've gone though the properties of all these blocks and compared them to the project that works and I don't see a difference at all. I'll attach the generated code here too (I think I did anyway)
This is leaving me with one of those eh? things... I don't see a difference between the running and non-running one but for the life of me I can't figure out why it doesn't like it. I'm guessing there is some setting somewhere else that's a problem but don't know where to look for this...
Any hints?
I did an experiment here this morning and deleted the middle (Rx) DTC driver on here. I have no recollection of why it's there to being with but my other (working) project has it so apparently it doesn…
Hi rjl,
How are things going? Were you able to find out the cause of the issue? I checked SSP 1.7.5 release notes but I wasn't able to find a known issue related to this one. Have you tried using a later version of SSP, maybe 1.7.8 or maybe the latest 2.4.0? To see if this problem is with the SSP version or with your code. This problem occurs when both I2C and I2S are used right? Or you can't also open the I2S channel when using other peripherals? Have you also tried following this I2S guide to see if you missed something: https://www.renesas.com/us/en/document/apn/audio-playback-i2s-framework-module-guide-application-project?
JBIf this response, or one provided by another user, answers your question, please verify the answer. Thank you!Renesas Engineering Community Moderatorhttps://community.renesas.com/https://academy.renesas.com/https://en-support.renesas.com/knowledgeBase/
This is mighty odd. I've got very similar (almost identical) code in another 1.7.5 project that hasn't got a problem. The difference is that this project got changed up from 1.2.x to this in an attempt to avoid the bug in the I2C driver. Right now I never get that far on this code to find out if the I2C driver is actually working or not.
Given the problems converting SDK versions I've had over the while, I'm not keen on attempting another version BUT I might need to go there to mitigate the I2C issues I've had here.
This particular problem appears to be fully something to do with the I2S driver since it's complaining about having, yet not having, a read portion to it. I don't use a read (this is write only) so it trips itself up and never goes any further in the open call.
I did an experiment here this morning and deleted the middle (Rx) DTC driver on here. I have no recollection of why it's there to being with but my other (working) project has it so apparently it doesn't actually do much anyway.
Once deleted, this comes up, opens and runs I2S out anyway.
So there's something odd about the project conversion there causing this to be a problem internally somehow. No idea why or how but deleting the DTC Rx causes it to run (or at least not barf during open())