cancel
Showing results for 
Search instead for 
Did you mean: 

STM32L476xx disambiguation

Noyb
Associate II
Posted on May 18, 2016 at 15:53

The original post was too long to process during our migration. Please click on the attachment to read the original post.
19 REPLIES 19
Posted on May 19, 2016 at 17:39

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...

JW
Noyb
Associate II
Posted on May 19, 2016 at 17:47

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.

Posted on May 19, 2016 at 22:50

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.''

JW

Posted on May 20, 2016 at 10:03

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

  ;

JW

Noyb
Associate II
Posted on May 20, 2016 at 10:15

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.

Walid FTITI_O
Senior II
Posted on May 20, 2016 at 19:19

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-

Noyb
Associate II
Posted on May 31, 2016 at 10:57

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...

Noyb
Associate II
Posted on May 31, 2016 at 16:40

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...

Walid FTITI_O
Senior II
Posted on September 14, 2016 at 16:01

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-
Imen.D
ST Employee
Posted on January 19, 2017 at 18:49

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

When your question is answered, please close this topic by clicking "Accept as Solution".
Thanks
Imen