I successfully tested setting and clearing the Access Window on a small Synergy S5D9 project on a PK-S5D9 evaluation board. This project was built with the IAR toolchain. My colleague could not get the same Access Window code to work on his S5D9 project that was built using the Gnu toolchain. He is getting a 0x2B error from SSP: SSP_ERR_INVALID_HW_CONDITION.
The SSP User Guide says this error can be avoided by making sure DTC/DMAC, EDMAC, or LCDC/2DG/JPEG are enabled. None of these are enabled in his code. Per the User Guide, he also defined R_FLASH_HP_CHECK_MODULE_STOP_BITS to 0, and called the recommended code
ssp_err_t err; ssp_feature_t ssp_feature = {{(ssp_ip_t) 0U}}; ssp_feature.id = SSP_IP_DTC;
err = R_BSP_ModuleStopAlways(&ssp_feature);
He seems to be doing everything right but keeps getting the 0x2B error. (My project also got the 0x2B error at the beginning before I followed the User Guide recommendations).
Could this problem be due to his using gcc instead of IAR?
Thanks.
The SSP V2.6.0 Users manual shows for the return value SSP_ERR_INVALID_HW_CONDITION :-
The configuration area cannot be writtenwhile DTC/DMAC, EDMAC, LCDC/2DG/JPEGare enabled.
This is to prevent prohibitedmemory accesses while the flash sequenceris running. Refer to the technical updatenumber TN-SY*-A033A/E.
This check can be disabled by definingR_FLASH_HP_CHECK_MODULE_STOP_BITS to0.
Thank you,
but as I said in the original post, we did follow the SSP Users Manual recommendations you mentioned and still saw the failure to affect the AWS register.
This is the way the MCU (core) operations with the normal interrupts but with the DTC that introduces another layer that will force different operations regarding interrupts to happen.
Refer to the ARM Core documents from ARM.
This is to do with the tech update :-
Limitations on programming the Option-Setting Memory for flash access applications (renesas.com)
If a bus master accesses a particular range of addresses while the Option Setting memory is being programmed, it can result in the programming to fail, or not occur correctly. This could mean the flash access window is not set, or set incorrectly, so I wouldn't recommend disabling the check by defining R_FLASH_HP_CHECK_MODULE_STOP_BITS to 0.
The check will check to see if the module stop bit of the bus masters in question have been set to 0, to enable the use of the modules in question :-
So if the the call
to R_FLASH_HP_AccessWindowSet() or R_FLASH_HP_AccessWindowClear() returns SSP_ERR_INVALID_HW_CONDITIONthen one of the bus master modules is enabled, and the programming of the Option setting memory could be at risk of falling foul of the issue in the tech update.
It is not compiler dependant, it just depends if the module stop bits in question are enabled (set to 0) when the Flash API in question is called.
If you think you are defining R_FLASH_HP_CHECK_MODULE_STOP_BITS to0 and the API call is still returning SSP_ERR_INVALID_HW_CONDITION when you call the API, then you probably are not defining it in the correct way.
However, as I said, I would not recommend disabling the check.