search

eupn / stm32wb-pac

A peripheral access crate for STM32WBxx Cortex-M4F BLE/IEEE 802.15.4
2 stars 1 forks source link

SPI: DFF vs CRCL #1

Open rubdos opened 3 years ago

rubdos commented 3 years ago

Reference manual (Multiprotocol wireless 32-bit MCU Arm®-based Cortex®-M4 with FPU, Bluetooth® Low-Energy and 802.15.4 radio solution - Reference manual) says:

image

SVD says: 

<field>
   <name>CRCNEXT</name>
   <description>CRC transfer next</description>
   <bitOffset>12</bitOffset>
   <bitWidth>1</bitWidth>
</field>
<field>
   <name>DFF</name>
   <description>Data frame format</description>
   <bitOffset>11</bitOffset>
   <bitWidth>1</bitWidth>
</field>

Should this be reported to ST, and meanwhile be patched here? This is related to https://github.com/eupn/stm32wb-hal/pull/2

eupn commented 3 years ago

Wow, nice catch! ST is known for its buggy SVDs so we should always double-check against the RM if we're facing issues. You should report it to their support (but don't expect an answer or an update to SVD) and patch the SVD/PAC meanwhile.

rubdos commented 3 years ago

Caught it when I was playing with the 8-bit and 16-bit SPI modes, noticed that the DFF was abandoned in favour of some bits in CR2... I'll contact ST.

rubdos commented 3 years ago

I've filed the report, and noticed it is still apparent in the 1.7 SVD (we're currently at 1.6). We should probably first update to 1.7 and then add the patch on top of that.

rubdos commented 3 years ago

Response from ST:

Thank you for reporting this problem. We always appreciate when bugs are reported back to us. It helps a lot to improve the quality of our products and ecosystem.

Indeed, I did a quick check and (as you suggested) this error is present for all the WB family (WBx0/WBx5). So, I have forwarded this case to the documentation team, and it should be corrected in future release.

I also forwarded your GitHub invitation to my colleagues.

Thank you again and I wish you a Happy New Year!

(I had invited them to comment here :-) )

eupn commented 3 years ago

@rubdos thanks a lot for tackling this and reaching out to ST! I've noticed some mistakes in SVDs during my work with this chip too.

I'm in process of integrating (https://github.com/stm32-rs/stm32-rs/pull/467, https://github.com/stm32-rs/stm32-rs/pull/473) this crate into the stm32-rs ecosystem and it'll make sense for us to move our further discussion and patches there.

karlp commented 3 years ago

As you're moving stuff to stm32-rs, and there's a crate there https://crates.io/crates/stm32wb, what does this one provide that's different? I see that https://github.com/stm32-rs/stm32-rs/pull/473 is still unresolved, but is the intent that dependencies like stm32wb-pac in the https://github.com/eupn/stm32wb55 repo will switch to that crate instead of this one?

eupn commented 3 years ago

@karlp yes, I want to eventually merge into the stm32-rs ecosystem and the first step to do this is to resolve the abovementioned issue (https://github.com/stm32-rs/stm32-rs/pull/473). Before that, one could rely on this crate instead.