Can ST please quantify waitstates imposed by accessing ETH registers

[waclawek.jan]

ETH is obviously a dual-clock peripheral, and some of the registers are most probably behind a synchronizer, in the MII clock domain. It’s not unlikely that reading some of those registers imposes waitstates. Writing may not, but then those are subject to the Successive write operations to the same register might not be fully taken into account erratum (which hints at the fact that there’s a 4-MII-clock synchronization mechanism, at least for writing).

Can ST confirm or deny, whether reading and/or writing ETH registers imposes waitstates, and in case of yes, can ST please list related registers and also quantify number of waitstates. Here’s why.

In particular, we need this to be quantified for the ‘F4xx, but for other families it would be a bonus to have this, too.

Thanks,

JW

[mƎALLEm]

Hello ​@waclawek.jan ,

I’ll forward your request internally. I’ll get back to you as soon as I have a feedback.

[mƎALLEm]

Hello ​@waclawek.jan and sorry for the late reply.

Just received an answer from our expert confirming that reads and writes to the ethernet registers do not cause wait states. Therefore, no ETH registers are affected, and no additional wait states are needed for register access.

Hope that answers your question.

[waclawek.jan]

Hi ​@mƎALLEm ,

Thanks for the info.

JW

PS. Can you please select your post as the answer - I don’t have that option probably because this thread was created in Khoros before the transition.

[mƎALLEm]

Hi ​@waclawek.jan ,

Thank you.

PS. Can you please select your post as the answer - I don’t have that option probably because this thread was created in Khoros before the transition.

I think better to escalate that issue in Feedback forum. So we could confirm if the behavior is related to the migration or something else.

[waclawek.jan]

I did.

JW