2016-05-18 06:53 AM
2016-05-19 08:39 AM
Noyb,
please don't post replies by opening a new tab/window. That forks a new sub-thread with no title (you could see it switching the forum to threaded mode), and that results in all sorts of subsequent failures, including inaccessibility of the individual post, thus inaccessibility of the attachments to it... JW2016-05-19 08:47 AM
Love your tags...
If I do not open in new tab, the forum often returns me an error, and when I go back to resubmit my rant... input, it has disappeared. Lost many replies this way, which adds to my overall frustration.2016-05-19 01:50 PM
Hannibal,
While I did not rant along these lines on this forum for a few years now, I brought this issue up quite often on places where I knew people from ST participate, and in person. Some of my rants I collect into http://www.efton.sk/STM32/STM32F4xx_doc_errors.txt , known to some people in ST; this particular issue is represented there in this form:''With ALL stm32fxxx.h - PLEASE include non-single-bit values definitions, PLUS both the mask AND the lowmost bit definition, PLEASE, thank you. I am willing to cooperate/help/discuss.''
JW2016-05-20 01:03 AM
Ah, I see.
No, my point was, that *values* for bitfields are missing. Constants. ST defines these constants in the ''libraries'' (both SPL and Cube (and maybe third time in LL? I did not investigate)) in an unsystematic, haphazard fashion. For example: // trigger (TRGI) source #define TIM_SMCR_TS__ITR0 0 // slave -- see below for individual timers #define TIM_SMCR_TS__ITR1 1 #define TIM_SMCR_TS__ITR2 2 #define TIM_SMCR_TS__ITR3 3 #define TIM_SMCR_TS__TI1F_ED 4 // both edges on CH1 input #define TIM_SMCR_TS__TI1FP1 5 // TI1FP1 with the same polarity as if CH1 used for capturing in CC1 #define TIM_SMCR_TS__TI2FP2 6 // TI2FP2 with the same polarity as if CH2 used for capturing in CC2 #define TIM_SMCR_TS__ETRF 7 // external trigger input // individual internal trigger sources #define TIM1_SMCR_TS__TIM5 0 // TIM1 is triggered from TIM5 #define TIM1_SMCR_TS__TIM2 1 // etc. #define TIM1_SMCR_TS__TIM3 2 #define TIM1_SMCR_TS__TIM4 3 #define TIM2_SMCR_TS__TIM1 0 #define TIM2_SMCR_TS__TIM8 1 #define TIM2_SMCR_TS__TIM3 2 #define TIM2_SMCR_TS__TIM4 3 #define TIM3_SMCR_TS__TIM1 0 #define TIM3_SMCR_TS__TIM2 1 #define TIM3_SMCR_TS__TIM5 2 #define TIM3_SMCR_TS__TIM4 3 #define TIM4_SMCR_TS__TIM1 0 #define TIM4_SMCR_TS__TIM2 1 #define TIM4_SMCR_TS__TIM3 2 #define TIM4_SMCR_TS__TIM8 3 #define TIM5_SMCR_TS__TIM2 0 #define TIM5_SMCR_TS__TIM3 1 #define TIM5_SMCR_TS__TIM4 2 #define TIM5_SMCR_TS__TIM8 3 #define TIM8_SMCR_TS__TIM1 0 #define TIM8_SMCR_TS__TIM2 1 #define TIM8_SMCR_TS__TIM4 2 #define TIM8_SMCR_TS__TIM5 3 #define TIM9_SMCR_TS__TIM2 0 #define TIM9_SMCR_TS__TIM3 1 #define TIM9_SMCR_TS__TIM10 2 #define TIM9_SMCR_TS__TIM11 3 #define TIM12_SMCR_TS__TIM4 0 #define TIM12_SMCR_TS__TIM5 1 #define TIM12_SMCR_TS__TIM13 2 #define TIM12_SMCR_TS__TIM14 3 which then allows me to write stuff like TIM1->SMCR = 0 | (TIM1_SMCR_TS__TIM2 * TIM_SMCR_TS_0 ) // master is TIM2 | (TIM_SMCR_SMS__EXT_CLK_1 * TIM_SMCR_SMS_0 ) // external clock mode 1 ; JW2016-05-20 01:15 AM
Right, that's missing too, planned to do it by myself as I've already spent 4 days to create the file listed above. Will paste it there once finished. But for the L4, not the F4.
2016-05-20 10:19 AM
Hi waclawek.jan,
It's clear now, I see the file. I will check the content. Hi Noyb, I have checked and confirmed feedbacks except (case5, case25 and case4). Thank you all for your contribution. -Hannibal-2016-05-31 01:57 AM
Hi, I've just upgraded to MX 4.15 with files from 29-April-2016 (instead of 26-February-2016 for MX 4.14) and I wanted to check my reported cases, just to see if something has improved, even though the file modifications were done prior to our little conversation.
So I started with :Case 1 :
stm32l476xx.h (v1.1.0), l3673
#define DAC_SR_BWST1 ((uint32_t)0x20008000U) /*!<DAC channel1 busy writing sample time flag */
en.DM00083560.pdf, p567
17.5.14 DAC status register (DAC_SR)
Could you explain why this is not just 0x00008000U ? Why does it also features the DAC_SR_DMAUDR2 macro ? I compared with the new file, now every macro is split into 3 lines, one _Pos, one _Msk and one that is supposed to mimick the original macro (minus some macro renaming). What I get now :Case 1 :
stm32l476xx.h (v1.1.1), l6313
#define DAC_SR_BWST1_Pos (15U)
#define DAC_SR_BWST1_Msk (0x4001U << DAC_SR_BWST1_Pos) /*!< 0x20008000 */
#define DAC_SR_BWST1 DAC_SR_BWST1_Msk /*!<DAC channel1 busy writing sample time flag */
en.DM00083560.pdf, p567
17.5.14 DAC status register (DAC_SR) Now that bogus macro goes from 0x20008000 to... 0x800200000 (0x4001 << 15) Can you explain ? How long are we going to suffer this amateurish work of ST that is supposed to allows us delivering professional products ? Have I to spend days and nights debugging my software after each MX update ? Have we to use eol mcus to somehow ensure having stable and reviewed libraries ? I'm not even considering checking the next cases I reported. I'm fed up. Seriously...
2016-05-31 07:40 AM
Now that bogus macro goes from 0x20008000 to... 0x800200000 (0x4001 << 15)
Well, (0x4001 << 0x15) produces 0x800200000, (0x4001 << 15) do actually produces the expected bogus macro 0x20008000. Like before. When refactoring done right still goes wrong...2016-09-14 07:01 AM
Hi Noyb,
Yes you are right. This one is not well fixed, like it seems, due a typo of 0x4001U instead of 0x01U in the ''#define DAC_SR_BWST1_Msk'' macro. I report it internally to our development team. Sorry for the inconvenience that it brought to you. -Hannibal-2017-01-19 09:49 AM
Dear Users,
The issue regarding typos and wrong macros/defines is already fixed in the firmware package STM32CubeL4.
Thank you for bringing this issue to our attention.
All your feedback are welcome.
Regards
Imen