Closed ghost closed 7 years ago
Hi,
No problem, thanks for contributing :)
This is one instance where Volatile_Full_Access is not the best option, it's also the case with shadow registers.
Here's a workaround:
-- Store a copy of the entire register in a variable
CCR : CCR_Register := STM32_SVD.QUADSPI.QUADSPI_Periph.CCR;
begin
-- Configure communication in the CCR variable
CCR.DDRM := ...;
CCR.DHHC := ...;
...
CCR.INSTRUCTION := ...;
-- Write the entire register at once:
STM32_SVD.QUADSPI.QUADSPI_Periph.CCR := CCR:
Regards,
Hi,
Thanks for your reply and your workaround ! It's working like a charm :-)
Best regards,
You are welcome :)
Hello,
First of all I am kind of new with Ada so if my issue is not a real issue but a miss-use of your SVD files, sorry for that.
I am trying to use the QUAD-SPI of my STM32F767 using your STM32F7 SVD files.
I currently use directly the "QUADSPI_Periph" object from the file _Ada_Drivers_Library/arch/ARM/STM32/svd/stm32f7x9/stm32svd-quadspi.ads.
From the STM32F7 Reference Manual, the Quad-SPI communication starts as soon as we wrote into the QuadSPI_CCR.INSTRUCTION register (which has a size of 8 bits).
For example, I am using your object like this :
Once I setup my communication frame format, trigger the communication by writing into INSTRUCTION
The problem is that the CCR register is defined as a "Volatile_Full_Access" like this :
With this pragma, I suspect that my instructions above, when configuring the CCR modes independently, wrote several times inside CCR.INSTRUCTION and then, the Quad-SPI peripheral tries to start several communications.
I currently don't have a solution to propose (exepecting creating manually several pointers to the right locations... but I would prefer a way to fix the SVD descriptions, these descriptions are so helpful !)
So, let me know what do you think.
Best regards, FG