Comments (18)
Hi Pavel,
The fix of this issue will not be part of the v1.7.0 pacakge which will be published soon but part of a later one.
In the meanwhile, here is how the erroneous line will be updated:
-WRITE_REG(heth->Instance->DMACRDTPR, ((uint32_t)(heth->Init.RxDesc + (((uint32_t)(ETH_RX_DESC_CNT - 1))*sizeof(ETH_DMADescTypeDef)))));
+WRITE_REG(heth->Instance->DMACRDTPR, ((uint32_t)(heth->Init.RxDesc) + ((uint32_t)(ETH_RX_DESC_CNT - 1))));
We hope this helps and we thank you once more for your contribution.
With regards,
from stm32cubeh7.
Hi Pavel,
Thank you for having reported this point. It will be transmitted to our development teams. We will be back to you as soon as they provide us with a feedback. Thank you once more.
With regards,
from stm32cubeh7.
Thank you Ali. Kudos for finding this issue go to ashchepkov581 (on the forum).
from stm32cubeh7.
Hi Pavel,
Our development teams confirmed this issue. A fix will be implemented and published in the frame of a future release. Thank you again for your contribution.
With regards,
from stm32cubeh7.
ST Internal Reference: 76913
from stm32cubeh7.
Still not fixed in v. 1.6.0
from stm32cubeh7.
Hi Pavel,
This bug is intended to be fixed in the frame of package v1.7.0 release (or a later one).
With regards,
from stm32cubeh7.
Ali, could they review it again, please? Per the docum (RM0433 page 2889) ETH_DMACRXDTPR indicated location of the last RX descriptor. I understand this as it contains address of the last descriptor, that is (base addr) + sizeof (one descr) * (number of desc. -1)
But in their variant: (base addr) + (number of desc. -1).
-- pa
from stm32cubeh7.
Hi Pavel,
I had a look to the ETH_DMADescTypeDef structure type and I think I understand better your point. Would you confirm please before I loop back with our development teams? Thanks.
Below is the definition of the ETH_DMADescTypeDef structre type:
STM32CubeH7/Drivers/STM32H7xx_HAL_Driver/Inc/stm32h7xx_hal_eth.h
Lines 57 to 65 in 79196b0
Now, sizeof(ETH_DMADescTypeDef)
would return 24 (6 members x 4 bytes per member).
And here is the point:
- On the one hand, removing the
sizeof(ETH_DMADescTypeDef)
from the expression would not yield the correct result, as you are saying (resulting address less than the targeted one). - On the other hand, leaving the
sizeof(ETH_DMADescTypeDef)
as it is would not yield the correct result neither (resulting address greater than the targeted one).
Rules of pointer arithmetic require rather the following:
sizeof(ETH_DMADescTypeDef) / sizeof(uint32_t)
Correct implementation would then be:
-WRITE_REG(heth->Instance->DMACRDTPR, ((uint32_t)(heth->Init.RxDesc + (((uint32_t)(ETH_RX_DESC_CNT - 1))*sizeof(ETH_DMADescTypeDef)))));
+WRITE_REG(heth->Instance->DMACRDTPR, ((uint32_t)(heth->Init.RxDesc) + (((uint32_t)(ETH_RX_DESC_CNT - 1)) * (uint32_t)(sizeof(ETH_DMADescTypeDef) / sizeof(uint32_t)))));
With regards,
from stm32cubeh7.
Ali, sorry for delay. So now there are two "correct" variants. (I assume that red line with - is wrong and green line with + is proposed correction).
I'm confused.... where is pointer arithmetic in (uint32_t)(heth->Init.RxDesc)
? If it were (uint32_t*)(heth->Init.RxDesc)
then maybe... Lets' ask help from the ethernet experts on the forum.
Regards,
Pavel
from stm32cubeh7.
I think @ALABSTM is right. The correct calculation should be (uint32_t)(heth->Init.RxDesc) + offset_bytes
I meet this issue and debug for half of day. I can't believe this bug is not fixed for this long time.
from stm32cubeh7.
Hi Pavel,
Pointer arithmetic arrives on the scene because structure member RxDesc
is actually a pointer to the first DMA Rx descriptor.
Hence, as
RxDesc
points on a ETH_DMADescTypeDef
structure, expression (uint32_t)(heth->Init.RxDesc + (uint32_t)1)
, for instance, will be automatically reevaluated @firstRxDesc + sizeof(ETH_DMADescTypeDef)
.
To conclude, first fix suggestion is the correct one as confirmed by @kele14x.
-WRITE_REG(heth->Instance->DMACRDTPR, ((uint32_t)(heth->Init.RxDesc + (((uint32_t)(ETH_RX_DESC_CNT - 1))*sizeof(ETH_DMADescTypeDef)))));
+WRITE_REG(heth->Instance->DMACRDTPR, ((uint32_t)(heth->Init.RxDesc) + ((uint32_t)(ETH_RX_DESC_CNT - 1))));
The above expression (in green) will be automatically reevaluated @firstRxDesc + (ETH_RX_DESC_CNT - 1) * sizeof(ETH_DMADescTypeDef)
.
I hope this makes things clearer. Please do not hesitate if you still have questions about the suggested fix.
With regards,
from stm32cubeh7.
Ali, @kele14x, with all respect it seems there's some misunderstanding.
I put a little example here to explain: rextester.com/LRKA74918
As soon as you cast a pointer to a number (uint32_t)(heth->Init.RxDesc)
, it becomes a number and pointer stuff no longer applies to it.
However, as @alister commented on the forum, it looks like there are multiple variants of setting this register, depending on the overall design of the driver. If the person who proposed the correction will provide also a thorough fix of the ETH driver, he/she likely knows better. If such fix won't be provided, this issue alone is not important.
Regards,
Pavel A.
from stm32cubeh7.
Hi Pavel,
I confirm there is a misunderstanding and a typo (from my side) too. In the expression I reported of the suggested fix, parenthesis are not correctly placed. With such an expression, pointer arithmetic applies no more. You are absolutely right about it.
The fix would rather be:
-WRITE_REG(heth->Instance->DMACRDTPR, ((uint32_t)(heth->Init.RxDesc + (((uint32_t)(ETH_RX_DESC_CNT - 1))*sizeof(ETH_DMADescTypeDef)))));
+WRITE_REG(heth->Instance->DMACRDTPR, ((uint32_t)(heth->Init.RxDesc + (uint32_t)(ETH_RX_DESC_CNT - 1))));
I hope you agree on what is written here. I do apologize for the confusion caused.
With regards,
from stm32cubeh7.
Ali, no problem, thanks for checking. The bigger question now is, how about a deeper revision of the eth driver? When this could be expected?
- P.
from stm32cubeh7.
Hello Guys
I have question if we are changing the RX descriptor tail pointer address.
Do you think the TX descriptors should also be change from
/* Set Transmit Descriptor Tail pointer /
(Line 2663) WRITE_REG(heth->Instance->DMACTDTPR, (uint32_t) heth->Init.TxDesc);
to
/ Set Transmit Descriptor Tail pointer */
(Line 2663) WRITE_REG(heth->Instance->DMACTDTPR, ((uint32_t)(heth->Init.TxDesc + (uint32_t)(ETH_TX_DESC_CNT - 1))));
Please let me know if there is any difference in TX and RX descriptors. I am not expert on this Ethernet HAL handling on stm32h7.
Thanks
Tushar
from stm32cubeh7.
@tushartp You're welcome to ask this in the forum.
from stm32cubeh7.
To make the code's intention clearer, I would suggest
WRITE_REG(heth->Instance->DMACRDTPR, (uint32_t)(&heth->Init.RxDesc[ETH_RX_DESC_CNT - 1]));
Much clearer, and doesn't require knowledge of pointer arithmetic rules.
from stm32cubeh7.
Related Issues (20)
- HAL_UART_Transmit can generate faulty error HOT 7
- Possible Duplicate of Issue 99 on the F7 Repository HOT 1
- USB composite CDC-CustomHID device problem, one of I/F hangs or data corruption occurs HOT 7
- STM32H7B3I-DK PLL3 VCO output exceeds 560MHz limit HOT 3
- "BSP" example for STM32H747I-DISCO is missing in the repo HOT 1
- IWDG Max timeout value
- H7B3: USB with DMA generates many interrupts HOT 1
- Configuration register SYSCFG_PMCR set wrong value when config pins like PC3_C as GPIO HOT 2
- STM32H725 and FreeRTOS doesn't generate timer IRQ correctly. HOT 3
- Wrong implementation of HAL_RCC_GetSysClockFreq, LL_RCC_CalcPLLClockFreq as well as SystemCoreClockUpdate in the examples HOT 1
- Missing WIFI, Clock and Weather Example in Latest Update HOT 1
- initialisation setting for USB_OTG_HS as a disable HOST fails to return from init when using FW_H7 v1.11.2. (not so with v1.11.1 HOT 8
- Unexpected Closed Socket Error in AT_ExecuteCommand when Joining a a Network after Update HOT 4
- register storage class specifier is deprecated in C++17 HOT 4
- A bug in the HAL_I2C_IsDeviceReady function in version 1.11.3 HOT 4
- v1.11.2 changes to lan8742.c result in hardfaults HOT 6
- FDCAN FDCAN_RxHeaderTypeDef.data_length is always 0 HOT 6
- FDCAN HAL_FDCAN_ConfigGlobalFilter() doesnt filter HOT 4
- Generate the ADC code for the STM32H750 using CUBEMXV6.11.1, where the Oversampling Ratio must use ADC3_OVERSAMPLING_RATIO_XXX, but an error occurs when compiling. HOT 1
- JPEG utils not setting ConvertedDataCount variable in YCbCr to RGB functions HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from stm32cubeh7.