STM32 direct register write to DAC1,2,3. - Page 1
Forum section: electronics / general

author: MT
author_rank: Super Contributor
timestamp: October 02, 2015, 04:10:43 pm
content: I have gone totally blind!Does anyone know how to do a direct register write to DAC1,2,3 on a F303, F334, F358 to output a simple dc voltage?I got floating PA4,5,6 despite dac enabled, clock enabled and also no data is seen in the DOR register.In stm32f30x.h only a offset is defined:#define DAC_DHR8R1_DACC1DHR ((uint8_t)0xFF)The compiler is not complaining over:DAC->DHR8R1= 127;Despite it's totally wrong.How are DAC1,2,3 actually defined because there is only:#define DAC_DHR8R1_DACC1DHR ((uint8_t)0xFF)#define DAC_DHR8R2_DACC2DHR ((uint8_t)0xFF)Thanks for your effort and time!

author: newbrain
author_rank: Super Contributor
timestamp: October 02, 2015, 04:49:56 pm
content: Which specific stm32f30x.h are you looking at?In CMSIS all the DAC registers are defined in the specific processor include, e.g., in stm32f303x8.h:Code:typedef struct{__IO uint32_t CR; /*!< DAC control register, Address offset: 0x00 */__IO uint32_t SWTRIGR; /*!< DAC software trigger register, Address offset: 0x04 */__IO uint32_t DHR12R1; /*!< DAC channel1 12-bit right-aligned data holding register, Address offset: 0x08 */__IO uint32_t DHR12L1; /*!< DAC channel1 12-bit left aligned data holding register, Address offset: 0x0C */__IO uint32_t DHR8R1; /*!< DAC channel1 8-bit right aligned data holding register, Address offset: 0x10 */__IO uint32_t DHR12R2; /*!< DAC channel2 12-bit right aligned data holding register, Address offset: 0x14 */__IO uint32_t DHR12L2; /*!< DAC channel2 12-bit left aligned data holding register, Address offset: 0x18 */__IO uint32_t DHR8R2; /*!< DAC channel2 8-bit right-aligned data holding register, Address offset: 0x1C */__IO uint32_t DHR12RD; /*!< Dual DAC 12-bit right-aligned data holding register, Address offset: 0x20 */__IO uint32_t DHR12LD; /*!< DUAL DAC 12-bit left aligned data holding register, Address offset: 0x24 */__IO uint32_t DHR8RD; /*!< DUAL DAC 8-bit right aligned data holding register, Address offset: 0x28 */__IO uint32_t DOR1; /*!< DAC channel1 data output register, Address offset: 0x2C */__IO uint32_t DOR2; /*!< DAC channel2 data output register, Address offset: 0x30 */__IO uint32_t SR; /*!< DAC status register, Address offset: 0x34 */} DAC_TypeDef;Remember that writing to the data register is not enough, the DAC needs a trigger.If you enabled the SW trigger by setting the TSELx [x=1,2] bits in the CR to 111, to have the data transferred to DORx [x=1,2] you must set the SWTRIGx [x=1,2] bit in the SWTRIGR register.The bit will be cleared by the HW, signalling that the DAC is ready to accept another value.See pages 429 onwards of the reference manual for all the registers, and page 420 for the SW trigger description.Remember to define the pins as analog "In order to avoid parasitic consumption".But you might instead want to use the HAL...(I know your stance on the topic).Edit: later on in the .h, all needed bitmasks and base pointers are also defined.

author: MT
author_rank: Super Contributor
timestamp: October 02, 2015, 05:41:17 pm
content: QuoteSpecifically the latest stm32f30x.h dated 2015who covers 303, 334, 358, 328.QuoteI'm not using CMSIS!I hate CMSIS!But i do glare into 303SPL!But im not using it!QuoteI'm aware of TSEL ,etc, etc, im reading as my eyes bleed! Thats why i cant see the glory "obviousness" of ST!But i got the impression you can write directly without using any triggers. RM0316 quote:Depending on the loaded DAC_DHRyyyx register, the data written by the user is shiftedand stored into the corresponding DHRx (data holding registerx, which are internalnon-memorymapped registers). The DHRx register is then loaded into the DORx registereither automatically, by software trigger or by an external event trigger.So this sign as i interpret that ""automatically" is the PCLK1 clk that shifts DHR8R1 datainto DHR1 , RM0316 also mentions one PCLK1 cycle to shift for anything that is not using trigger.Why would you have atrigger enable registerif trigger was always the default way to get data out of dac?It makes no sense RM0316 qoute!Bit 1 SWTRIG2: DAC channel2 software triggerThis bit is set and cleared by software to enable/disable the software trigger.0: Software trigger disabled1: Software trigger enabledNote: This bit is cleared by hardwarePins should also not float, RM0316 quote:Once the DACx channel y is enabled, the corresponding GPIO pin (PA4, PA5 or PA6) isautomatically connected to the analog converter output (DACx_OUTy). In order to avoidparasitic consumption, the PA4, PA5 or PA6 pin should first be configured to analog (AIN).And the do stop float when MODER is set from Analog to GEN. Also there is OUTEN1, 2 registerbits with no explanation in the ref manual only mentioned in the register map sharing positionwith BOFF, and where is DAC3 mentioned in your struct?? except for ST 303 eval main.c whichis pure bizzarness! How do you make a distinction between DAC1,2 and DAC 3 who isactually described in RM0316 as DAC channel 2, i assumed DAC1 channel2!?!QuoteMy stance on HAL is known!

author: newbrain
author_rank: Super Contributor
timestamp: October 02, 2015, 06:38:38 pm
content: Quote from: MT on October 02, 2015, 05:41:17 pmI see, oh, actually I don't. Where can I find that file? To answer your question I went to ST.com and dowloaded the F3 cube (I know, I know...) and the ref manual.That include file is not (AFAIK) in the cube, it seems...Quote from: MT on October 02, 2015, 05:41:17 pmFrankly, I'm lost. You are, of course, free not to use anything else provided by CMSIS and dislike it, but the device specific include files are there, withonly the register definitions, which I think is what you are somehow missing.The stuff brought in by including "core_mx.h" is, I would say, benign enough: some more definitions and static inline functions (that will not be there in the code if you don't use them). Same for system_stm32fxxx.h.Quote from: MT on October 02, 2015, 05:41:17 pmYou are of course right, making sure TENx bits are 0, I misinterpreted your needs.About OUTENx/BOFFx, I have never used the F3 (only F0,4,7) but, for what I can understand, some models have got a dual DAC and a half.DAC2 only output and DAC1 output2 are unbuffered. For those, you must set the OUTENx bit to 1 to connect the pin to the actual DAC output.Those bits are referenced in the diagrams at the beginning of the chapter, and then explained in the register description.Quote...but I definitely had missed your position on CMSIS!

author: MT
author_rank: Super Contributor
timestamp: October 02, 2015, 08:22:34 pm
content: QuoteI refuse to wrestle with Cube any more particularly after their latest 200megton gorilla release!The latest stm32f30x.h etc files is found instm32f30x_dsp_stdperiph_lib.zipgo to dedicatedSTM32F303 page and look for the dsp/spl library package.Actually it contain even more devices.QuotePardon?? Didn't you just say Cube didn't contain any register definitions? prior it was said it wasjust the typical warpping and call back stuff! If so what is then the point of having stm32f30x.h?!Would you mind post the section of that where DAC1,2,3 is clearly described?QuotePoint is not having everything split up and fragmented.The stm32fxxxxx.h files is not specifically located in CMSIS they are everywhere!Every time you download a lib or exampleor template you will find all kind of files. Since im on the dark side and do only register definition coding i want a bareminimum of files i dont want core or pheripherial (well i can accept that if it was clean) or any other abstraction garbagei want only one file containing definitions which is stm32f30x.h file in 2007 we had all that than ST destroyed it withSPL and HAL CMSIS.QuoteIf you look into stm32f3xxx_dac.h you will find the following text:#define DAC_Trigger_None ((uint32_t)0x00000000) /* !< Conversion is automatic once the DAC1_DHRxxxx registerhas been loaded, and not by external trigger */Compare that with reference manual andnote the significant differencequote:Depending on the loaded DAC_DHRyyyx register, snip.....snip....QuoteHehe, no device have half dac!There is 3 complete DAC's. ST just want to gorillafy the shit!F4 has same core and most peripherals as F3, very similar device.QuoteIt do seams so!QuoteWhat i suspected all along! vaguely describes the duality of the BOFF bit is from stm32f30x_dac.h file whichif ST had been sane would had been inside the reference manual. Still where is the definition and writeregister for DAC3? How do you write to DAC1 and half?For example writing to a PWM channel is simple....TIM2->CCR2=123;.... DAC should be equally simple.uint32_t DAC_Buffer_Switch; /*!< Specifies whether the DAC channel output buffer is enabled or disabled orthe DAC channel output switch is enabled or disabled.This parameter can be a value of @ref DAC_buffer_switch */So the conclusion we can draw from this is contrary to reference manual says it's not enough to enable DAC alone to get it going.QuotePage please!QuoteWhat is the bonafide to get entangled into CMSIS if i only want to stick to one manufacturer?thanks to ST even code on register level is not directly runnable if switching to another device insame family, well almost but certainly not from 103, 102 to F2 or F3 etc, even code based onold SPL and HAL has to me migrated (read: rewritten) to work!What about spelling errors in stm32fxxxx.h files? Code that once worked with 2011version is now defunct due to spelling errors from 2012 migrating into 2015 version!(i just discovered that one thank you very much ST)So what are you going to change? The register definition in the stm32f30x.h file,or your code or the referencemanual text? Maybe we should ask ST?

author: newbrain
author_rank: Super Contributor
timestamp: October 02, 2015, 09:47:03 pm
content: OK, I started late in this game, so I have no exposure to the SPL, my bad.But you don't have any need to wrestle, if you don't want to. 200MB (about half a Giga expanded) are not that much for today's computer.I don't see where I said that Cube does not include the reg definition, albeit I assuredly concede the eventuality that from my imperfect commandeering of the English language, not my mother tongue, ensues the failure to convey my inner elucubrations.Cube contains a lot of stuff, HAL, BSPs, code examples, horrific documentation (doxygen...I prefer reading the code), and yes, the dreaded CMSIS.Just for kicks, I downloaded also the SPL, and had a look at the file you mentioned. It's basically the same as the one in the Cube (did not do a diff, but they really look the same), and if you use it, you are also using CMSIS (it itself is inside the CMSIS dir tree):Code:#include "core_cm4.h" /* Cortex-M4 processor and core peripherals */DAC Register names: lines 648 onwardDAC base addresses: lines 1231-1234DAC pointers: lines 1344-1346DAC bitmasks: lines 5152 onwardYou really really don't want to use CMSIS? Take this file, physically include the lines needed to define base ARM features (core_mx.h stuff) and live happy ever after.As for DACs, it was half a dual DAC 1 Dual + 1/2 Dual = 3, that's ST math for you, F4 and F7 have only one dual DAC, both channels buffered (going from memory).So, in the F3s with three channels, there is no DAC3, there's a DAC1 (aliased to DAC) with two channels (as in F4-7) and a DAC2 with only one unbuffered channel.You don't write to DAC3, you write to the first channel of DAC2.Look at the registers scheme: each configuration register has one channel in the higher and one in the lower half-word.Data registers can be written independently or, in dual mode, both at the same time if desired.Picture for the bits on pages 415 and 416 (see pics), description on page 417 paragraph 16.3.2 and again in the register description, pages 431 and 433.So the ENx bits will enable the DAC, but the unbuffered channels will not be connected to the pin if you don't set OUTENx.Have a good night,newbrain

author: MT
author_rank: Super Contributor
timestamp: October 03, 2015, 02:07:55 am
content: Well its late, i just realized i been looking into V1 of RM0316, you are looking at V3 so my bad the graphics in V1 is quite different!In the mean time ST have released V5 but labeled it as V6 on their site!prior to this i actually got hold of some dac addresses.QuoteWell, host , snörvel som det heter på svenska!To download a 200megaton gorilla just to get the address of a DAC or 3 DACs inthis case each 2 bytes long and should have been inside the stm32f30x.hregister definition filein the dac section from thestart is kind of insane. But if you enjoy insanity i respect that!QuoteSee even you dont like CMSIS. Come, come, join the dark side!QuoteNo its just CIMSIfied, you can CIMSIfy anything and claim it's CMSIS.QuoteBut that we allreday know about, the register definition file, but why are you relabeling stm32f30x.h as a CMSIS file just becauseST have CMSIfied it or whatever?? I'm confused, core_cm4.h dont contain what you counted up there,it contains only syscore stufflike systick, nvic etc.QuoteIm completely lost, what do you mean by CMSIS? CIMSIS is just a convoluted mess of interentangled layers and blocks of garbageclogging up my brain which makes me constantly slide out of the flow and not a specific register definition file. CMSIS is just a namefor an atempt to standarize the way of developing code accross many manufacturers while making everyones MCU code bloated bothin speed and memory usage. That's why you should not use it. As the hocker said: the dick locks posh but it aint stiff!QuoteWhat file? ST have to include whatever they should include and keep all the garbage out!Have you ever come across lets say a MPS430 or AVR or dSPIC33, PIC32MX register definition files?There is no CIMSIS.QuoteWell, at first you didnt even know it was possible to do direct writes to DAC.So using CMSIS didnt help you at all.Alsing DAC's etc ,yes we allredy sorted that out 2 posts ago im afraid. Yes there is a third dac. No there is no such thing as one dualdac. Yes each dac is a block consisting of a "resistor string and a latch" the rest is just stupid ST convoluted naming. So yes there isdefenitively a physical third dac. A single dual dac or "half dac" or channell dac's as you stubbornly maintian is when exist is called a"TDM, time divisioned multiplexed dac" who often uses a mux which no STM device have..Btw, in v1 of RM0316 there is missing info, not my fault! Didnt you read what i initially wrote? It's quite known since long time ST refmanuals is rather poor and often in an unfinished state. Take F103 for instance ST have managed to do 15 revisions of the document! I wonder if there is any other MCU manufacturer with such a poor quality record!But thanks anyway newbrain it was entertaining to wrestle arguments about the insanity around ST!Btw,DAC3 is still dead!

author: newbrain
author_rank: Super Contributor
timestamp: October 03, 2015, 09:13:52 am
content: I'll just answer some point, but I won't put any more time in this.QuoteI like to span from the dark to darkest through gray to the bright and brightest, I have no technical religion.Linux, Win, PC, MAC, assembler, C++, direct register writes and HAL (there, I said it!) all have their place.QuoteThis is the part I'm having problems with.All the DAC reg defs you needareinside that file, and I showed you exactly where (admittedly, with a formatting slip):Code:DAC Register names: lines 648 onwardDAC base addresses: lines 1231-1234DAC pointers: lines 1344-1346DAC bitmasks: lines 5152 onwardThat file includes also the lower level part of CMSIS (core_m3.h), that contains ARM vendor independent common registers and definition.You don't need anything above that. If you're not comfortable with the bloat (which will just sit there, gathering bit dust), prepare your files based on this.Should ST provide a CMSIS liberated version?Yes, maybe. Another piece of code fro them to maintain and to keep in synch, for a very limited audience.You are welcome to disagree.Code:Take F103 for instance ST have managed to do 15 revisions of the document!I don't know and do not make assumption about your experience, but rest assured that having revisions is a actuallya good thing.Humans are not perfect, and faults slip through even with finely tuned processes and reviews, especially with complex stuff.If you have no revisions, it means the product is abandoned, obsolete or nobody is really using it.Just from the first MCU datasheet I had on hand (ATmega 328):Code:41. Datasheet Revision History41.1 Rev. 8271I – 10/201441.2 Rev. 8271H – 08/201441.3 Rev. 8271G – 02/201341.4 Rev. 8271F – 08/201241.5 Rev. 8271E – 07/201241.6 Rev. 8271D – 05/1141.7 Rev. 8271C – 08/1041.8 Rev. 8271B – 04/1041.9 Rev. 8271A – 12/09So, always check to have the latest docs, especially if something is not clear.Code:Well, at first you didnt even know it was possible to do direct writes to DAC.Do not assume what I know or don't know.I understand perfectly how a DAC works, thanks.My EE Master is still on the wall, last I checked (in a drawer, actually).Whether it's good or bad that ST decided to make it easy to configure and access two DAC channels at the time, I leave to your judgement.Dual means that, yes there are two physical DACs, but they are sharing registers and other stuff (e.g. Vref)This not uncommon, even as nomenclature, e.g. from MCP4922 DS (emphasis mine):Code:The MCP4902/4912/4922 devices are _dual_ 8-bit,10-bit, and 12-bit buffered voltage output_Digital-to-Analog Converters_ (DACs)It's a sunny Saturday, at least in the capital, take a break from this stuff and relax. My bike is waiting for me.

author: MT
author_rank: Super Contributor
timestamp: October 04, 2015, 12:43:52 am
content: Quote from: newbrain on October 03, 2015, 09:13:52 amYour wellcome.QuoteForgot to mention Commodore ,ATARI and Sinclair Spectrum.QuoteProblems with the stm32f30x file as file? Really? You rather download 500Mbytes just to get a single header file? Serious? For kicks?QuoteTrying to build a solid case just to write me my nose? It's more likely yourself dont know how to get DAC work, else you hadent ranted so much about the obviousness of stm32f30x.h, btw i didn't say anything more significant then stm32f30x.h....why else this thread.QuoteSo guru Clive1 and Jan is a limited audience, well one more file would tip the ST abstraction mountain over?Shurely mr Holmes you must be joking, as they say in the TV series.ST issues have been brought up by ton's of people over the years, not going to do it again but just sayyou said it your selfin prior posts. ST will likely slowly drown in their own CMSIS/HAL sync "wathever" maintenance mountain. Add another CMSIS block, call it CMSIS DSP, call it CMSIS RTOS, well supprice they allready did and they will continue to CIMSIfy until you as a coder drown in convoluted abstracted gigabytes...A software coder who cant write decent condenced clear code on bare metal using the path of least resistance is not a decent coder.No merrits and prestige in keeping high tresholds, steep learning curves, bloated tools, complicated pheripherials etc...Not an excuse to use xzcywhateverIOTOGGLE() just to toggle a pin and when pin dont toggle HAL/CMSIS coder turns to STM Forumandask Clive1 for helpbecauseST dont give a crap! ST asked people to DISCO with them but when they enter the dance floor ST suddenly stands offside pointing fingers.It's interesting to watch ST , CooCox etc forums 98,9 % of the questions is about why pheripherials dont work or how-do-i-get -this-pheripherial-to-work. Obvious reasons, perhaps complexity leads to CIMSIfycation backed by poor documentation.Btw a old colleauge called the other day begging for help, he had been given by his boss a Frescale ARM device that had a timer pheripherial that had 144 registers! I told him i have 80 registers of my own to faff with, he almost cried yet the guy is a 30+years EE Master engineer, im not! Im not even a coder , im certified gardener! You are asking me to comprehend? Please newbrain step down from your high horses for a moment.QuoteYes you do.QuoteI assume you troll, but will reply.I have done H/W engineering for 30 years at various BIG corporations (slapping my big baugette on the desk with a splash) and gardening for 40 years and piloting for 50 years and we have had ton's of 1.1 products with 1.1 documentation revisions rolling out of factory years upon end. Reason? Because we made sure we had professional engineering on all levels and well tought out and professionaly driven documentation processes. What you say is pure nonsense and a strawman argument! Perhaps you are one of their paid fanboys who under all circumstances want to defend ST's sloppy craftmanship, or even a ST employee?Humans are not perfect you say while being completely "blind folded" from their spelling errors. Well do ST even use computer basedspell checkers? They do?! How come spelling errors for years is migrating into new revsions? Perhaps their spell program is based on CIMSIS and HAL? Who knows! All i know is that wen a spell error is loctaed inside a register definition file things either dont work or stop working.Its bad enough they are in reference manuals.QuoteNice move there trying to write me on my nose, yet you used a old version 3 claming it was not possible to do direct DAC writes.Do your homework before asking everybody else to do theirs.QuoteNo you dont! read your own posts. No need to assume so stop writing me and others on our noses and drop the prestige stuff!QuoteAre you even aware "what" you are saying? We could possible cogitate, dwell on ,brood further on but no engineer with EE Masteri known for past 30 years have ever claimed half a DAC exist..... But you are wellcome to dissagree.QuoteChill out on the bike!