Which mainstream micros have the worst documentation, buggiest silicon etc. - Page 1
Forum section: electronics / general

author: e100
author_rank: Frequent Contributor
timestamp: August 21, 2019, 06:33:26 am
content: Or to put it another, way which micros cause you to spend lots of time searching forums for fixes to things that are supposed to work, but don't?

author: westfw
author_rank: Super Contributor
timestamp: August 21, 2019, 10:08:10 am
content: “We” just noticed that the initial 8-pin tiny-0 and tiny-1 AVR DataSheets (attiny412) fail to mention that there are pins connected to most of the timer compare outputs. That’s a pretty big mistake - 1 pwm output vs 5!I normally like the Atmel/microchip data sheets - they tend to be clear and well written and understandable. But there have been some big mistakes recently. Apparent cut&paste errors from othe chips in the same family, paragraphs on setting up the UART fifo using a register that doesn’t exist...Fun times!

author: nctnico
author_rank: Super Contributor
timestamp: August 21, 2019, 10:40:31 am
content: Microchip and Atmel are on my blacklist for various reasons. ST microcontrollers can also be quite finicky to work with.

author: ddavidebor
author_rank: Super Contributor
timestamp: August 21, 2019, 11:36:10 am
content: I have found myself always a bit disoriented from ST uC datasheets, despite loving the STM32 series and their development tools.Don't know why.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: August 21, 2019, 10:21:05 pm
content: Quote from: e100 on August 21, 2019, 06:33:26 amThe newest ones !

author: bd139
author_rank: Super Contributor
timestamp: August 21, 2019, 10:34:53 pm
content: Quote from: nctnico on August 21, 2019, 10:40:31 amThat's basically most of them isn't it?Z80 still has some weird in it even after 40 odd years.

author: MT
author_rank: Super Contributor
timestamp: August 22, 2019, 12:26:02 am
content: STM32 a pain in the arse basically since i worked most with them but recently there have been a upgrade, the language is different also the documentation style is quite different for some devices, so it seams they finally have hired some native English speaking manual writers. But in general people come and go in documentation departments, companies are bought and sold, back in the day Phillips was always among the best and everyone else the worst.....sort of..... depends on product to i suppose.....But i can imagine others alot worse then ST...i just havent worked with their docs yet.

author: garethw
author_rank: Regular Contributor
timestamp: August 22, 2019, 06:57:55 am
content: I would compare MCU datasheets to kitchens. Cooking in your own kitchen where you know where everything is isn’t a problem. Try cooking in someone else’s. A little bit of time spent in someone else’s kitchen and you get to know where stuff is and the quirks.Sent from my iPhone using Tapatalk

author: e100
author_rank: Frequent Contributor
timestamp: August 22, 2019, 11:27:55 am
content: Can I turn the question around and ask which micros are least troublesome.In other words, most things do work just as they are supposed to

author: nctnico
author_rank: Super Contributor
timestamp: August 22, 2019, 11:49:21 am
content: Quote from: bd139 on August 21, 2019, 10:34:53 pmNo. Not by a long shot.

author: Dave_PT
author_rank: Frequent Contributor
timestamp: August 22, 2019, 02:23:18 pm
content: Renesas RX23T...

author: brabus
author_rank: Frequent Contributor
timestamp: August 22, 2019, 02:30:52 pm
content: Microcontrollers: Freescale i.MXAnalog: ST Application Notes. Very well written, but the calculations are often wrong!

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 22, 2019, 03:01:57 pm
content: Sorry about that, but... so far: the Kendryte K210. (Ok it's not mainstream...)Other than that, Microchip tended to release long errata for many of their MCUs. They used to have good documentation, I think not so much anymore.

author: aldi
author_rank: Contributor
timestamp: August 22, 2019, 03:48:19 pm
content: The wireless cortex series from Silicon labs. I've used the EFR32 series, and they are by far the most buggy/crappy I've ever used. Avoid them at all cost.

author: IDEngineer
author_rank: Super Contributor
timestamp: August 22, 2019, 05:13:30 pm
content: IMHO, the Microchip spec sheets are pretty well written. Sometimes the placement of data seems less than obvious, but so far it's always been in there with a single exception that I can remember in the last ~7 years or so. I'm speaking here of the PIC18 and PIC24 families.On the flip side, I find the STM32 family spec sheets to be almost unusable. So far the ones I've tried to use read more like marketing puff pieces, lacking very basic technical details that made it impossible for me to even determine if the part could do what I needed. I remain open minded since the STM32 is so popular - maybe it's just me.

author: mark03
author_rank: Frequent Contributor
timestamp: August 22, 2019, 05:14:55 pm
content: Quote from: aldi on August 22, 2019, 03:48:19 pmThe EFR32 saga suggests another rule of thumb, besides the one above about newer parts being buggier: Those parts which had repeated delays / broken promises in their release process may be wise to avoid! There are times when everyone in a company realizes they have a turd on their hands, but they have to at least recoup some of the development cost, so the only thing left to do is polish the turd as much as possible and hope for the best. We've all been there. You just don't want to be on the customer side of one of those parts.

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 22, 2019, 05:28:52 pm
content: Quote from: IDEngineer on August 22, 2019, 05:13:30 pmWith STM32's, the technical info is like spread out between datasheets and reference manuals. If you look at datasheets only, you won't get very far indeed.The Ref Manual for the STM32L4 series for instance is almost 1500 pages.

author: MT
author_rank: Super Contributor
timestamp: August 23, 2019, 03:21:46 am
content: Quote from: e100 on August 22, 2019, 11:27:55 am68HC11, HC811 HC11F1, etc but thats 3 decades ago. things was simpler then.Edit: like to add MSP430 untill and after TI mask revision period faffing.

author: amyk
author_rank: Super Contributor
timestamp: August 23, 2019, 03:30:10 am
content: Quote from: MT on August 23, 2019, 03:21:46 amI'll add 8051 to that list.I agree about ST's documentation; excepting some Chinese-translated docs, they've been the most memorably difficult to understand out of the dozen or so uC families I've looked at.Regarding PICs and their long errata, at least they have published errata...

author: nigelwright7557
author_rank: Frequent Contributor
timestamp: August 29, 2019, 10:49:54 pm
content: The PIC's tend to have bits all over the place.Things like powering up with A2D converter enabled when you want to use that pin as GPIO.I recently had a buffer problem on a PIC32.The buffer was getting corrupted.Turned out the buffer was being filled by USB via DMA and DMA doesn't update the cache.You have to make the buffer "coherent" so it isn't cached.

author: hans
author_rank: Super Contributor
timestamp: August 31, 2019, 08:14:06 am
content: => PIC32MZ (EC errata..)But still would like to call them out for integrating a USB2.0HS peripheral on their new chips (which for their EF series looks very attractive), but then go on to only provide register level documentation for the USB peripheral. No procedures, no step by step initialization or guides of doing things, nope.Either it is NDA (which seems strange to release half a document), or they really want to force you into using their Harmony framework. The latter sounds like a blunt mistake to me, as I don't see any reason why a manufacturer will force such a large dependency on their customers.This experience was quite orthogonal to me with the PIC32MX. I think I once wrote a driver for their ethernet MAC controller from scratch in a few hours.---I agree with the general consensus about ST. However, I would like to make a counter argument that their power consumption charaterisation for their L series part is very detailed. Of course any documentation will miss things at low power stuff (the golden standard is still experimentation and measure your application), but I found their datasheets revealing far more information than for example a modern MSP430 chip with FRAM, which seems to be lacking so much detail in that regard.

author: Kilrah
author_rank: Unknown
timestamp: August 31, 2019, 10:38:15 am
content: Quote from: hans on August 31, 2019, 08:14:06 amUSB-IF licensing shenanigans maybe? As in MCP can't include in their public datasheet stuff that would tell too much about what you're supposed to pay USB-IF to get?

author: T3sl4co1l
author_rank: Super Contributor
timestamp: August 31, 2019, 10:51:46 am
content: Quote from: hans on August 31, 2019, 08:14:06 amThe PIC24E series too. Nevermind that any PIC24 is a bizarre hack of PIC architecture with more bits, but apparently the E is particularly bad. I didn't work with it myself, but coworkers said it was a mess.Tim

author: Rerouter
author_rank: Super Contributor
timestamp: August 31, 2019, 10:54:09 am
content: Yeah gaps in the datasheet is annoying for some of the AVR stuff, e.g. there capsense peripheral, they have hardware in the device (registers that control it), to fairly accurately measure external capacitance, but its completely undocumented, only available through AVR studio.

author: hans
author_rank: Super Contributor
timestamp: August 31, 2019, 11:02:26 am
content: Quote from: Kilrah on August 31, 2019, 10:38:15 amYou can find far more USB2.0 HS peripheral documentation in datasheets of ATSAM V71 parts or STM32F4 series.Sure there will be gaps in any documentation, but outright not documenting a "flagship" peripheral (i.e. at the time of release there weren't many USB2.0HS + phy MCU's) is appalling.

author: TomS_
author_rank: Frequent Contributor
timestamp: August 31, 2019, 11:20:37 am
content: Quote from: e100 on August 22, 2019, 11:27:55 amDespite all of the negativity they seem to get, Ive had great success with Microchip and they are my go-to microcontroller. Any issues I have encountered have been my own fault for not understanding the peripheral properly.Maybe Ive just been lucky and havent used a PIC with buggy silicon yet.

author: mskeete
author_rank: Contributor
timestamp: August 31, 2019, 12:34:13 pm
content: I wish ST and (others) woud write documentation like thishttps://vivonomicon.com/2018/04/02/bare-metal-stm32-programming-part-1-hello-arm/https://vivonomicon.com/2018/04/20/bare-metal-stm32-programming-part-2-making-it-to-main/https://vivonomicon.com/2018/04/22/bare-metal-stm32-programming-part-3-leds-and-buttons/https://vivonomicon.com/2018/04/25/bare-metal-stm32-programming-part-3-5-supporting-multiple-chips/https://vivonomicon.com/2018/04/28/bare-metal-stm32-programming-part-4-intro-to-hardware-interrupts/https://vivonomicon.com/2018/05/20/bare-metal-stm32-programming-part-5-timer-peripherals-and-the-system-clock/https://vivonomicon.com/2018/08/23/bare-metal-stm32-programming-part-6-multitasking-with-freertos/https://vivonomicon.com/2018/09/05/bare-metal-stm32-programming-part-7-embedded-c-inheritance/https://vivonomicon.com/2018/12/28/bare-metal-stm32-programming-part-8-learn-to-debug-timing-issues-with-neopixels/https://vivonomicon.com/2019/07/05/bare-metal-stm32-programming-part-9-dma-megamix/

author: TomS_
author_rank: Frequent Contributor
timestamp: September 01, 2019, 07:17:29 am
content: Quote from: mskeete on August 31, 2019, 12:34:13 pmWow, thats excellent, bookmarking those!

author: IDEngineer
author_rank: Super Contributor
timestamp: September 01, 2019, 05:18:01 pm
content: Quote from: SiliconWizard on August 22, 2019, 05:28:52 pmYes, the PIC series has similar documentation, but the difference is you can do almost everything you want by only looking at the spec sheets. Those are typically a few hundred pages of searchable and categorized PDF and once you grok their organization things flow pretty smoothly.The PIC reference manuals probably add up to something in the 1500 page range, but I've only ever HAD to look at them once that I can remember, and that was for some obscure details regarding their internal oscillators.The point I'm trying to make is that the two families may have similar page counts, but at least the PIC families put most of what you need into a much smaller and more concise document so it's easier to find what you actually need to know. I'd been successfully using multiple PIC families for several years based solely on their spec sheets before I evenlearnedof the existence of their reference manuals, and only then because I went looking for (even) more detailed info on that oscillator question. Other than that one case, there's been no need for anything beyond the PIC spec sheets.

author: IDEngineer
author_rank: Super Contributor
timestamp: September 01, 2019, 05:33:14 pm
content: Quote from: nigelwright7557 on August 29, 2019, 10:49:54 pmThis is definitely true. To their credit, many (but not all!) times there are little side notes referring you to "Section x.y" so you can deal with such things. Your example of analog mode on an I/O pin is perfect... some of those pins have 5+ possible functions including a mix of analog and digital, and to prevent current source/sink issues due to midrange analog voltages at reboot those pinsmustdefault to analog mode. Confusion about that is one of the most common questions in the Microchip forums. The docs do have lots of cross-referencing about it, but I think I've found a missing place or two.Everyone's highly integrated microcontrollers pack a lot of functionality into a few pins. I'm just grateful that, at least with PIC's, I don't have to wade through literallythousandsof pages ofmultipledocuments to get started (which is reported to be the case for the STM32, earlier in this thread).The PIC's have their quirks just like every MCU, but at least they make it easy and fast for newbies to get started. And focusing on that is smart for Microchip, since those things are often what wins design-ins and thus production orders. I wish others would follow suit.

author: nigelwright7557
author_rank: Frequent Contributor
timestamp: December 03, 2019, 03:59:24 am
content: Quote from: nctnico on August 21, 2019, 10:40:31 amMicrochip seems to have most problems but they do have a massive range of devices.Their MPLAB X and Harmony have a few problems too.So does the PICKIT3.

author: brucehoult
author_rank: Super Contributor
timestamp: December 03, 2019, 07:32:53 am
content: Quote from: SiliconWizard on August 22, 2019, 03:01:57 pmChips out of China ... fantastic specs and price ... impossible to figure out... The GigaDevice GD32VF103 appears to be the same, but at least it's somewhat copying/compatible with an STM ARM chip.

author: SiliconWizard
author_rank: Super Contributor
timestamp: December 03, 2019, 03:42:16 pm
content: Quote from: brucehoult on December 03, 2019, 07:32:53 amWell, the Kendryte case is a bit specific.The chip itself has incredible specs. The team working on it is fully dedicated AFAIK, it's not like a huge company (like GD) just selling by the million units, and willing to make a copycat.But for some reason, they decided that releasing an SDK was enough for anyone to use their chip, and that a proper datasheet and ref. manual was optional. Users keep asking for docs, and they repeatedly get answered, either: "our team is too small, no time yet to write docs", "just use the SDK", or... no answer at all. They tend to just ignore the inconvenient queries, such as when I asked why they decided to disable the double-precision FP support, whereas the core is designed with a D extension.To me, it kind of looks like a typical "software team" of modern days, almost 100% software-oriented. A bit problematic when you're designing ICs. I'm not sure what they are really expecting out of this venture. Even if you can definitely prototype interesting things with the SDK, it doesn't seem reasonable to use an IC without any proper doc in a commercial product... Maybe they're just hoping to sell their IPs to a bigger fish, just like most start-ups.

author: Howardlong
author_rank: Super Contributor
timestamp: December 03, 2019, 04:27:52 pm
content: Quote from: nigelwright7557 on December 03, 2019, 03:59:24 amI used to be almost entirely PIC, using the entire range, until they produced their PIC32MZ EC series about five years ago. The silicon was so buggy I went to NXP and TI for a solution, but worse was that it took 18 months for Microchip to accept that the multiple high speed ADCs (at that time a USP) was for all practical purposes useless. I burned many months on a product assuming I just wasn't configuring it correctly.Although I do still use PICs most of the time, documented and undocumented silicon bugs are much more of a fact of life on their newer devices now. I have adapted my development regime appropriately, mostly be being much more likely to distrust the silicon than I once was.

author: westfw
author_rank: Super Contributor
timestamp: December 04, 2019, 03:23:06 am
content: QuoteAh. Gotta put in a word for FTDI's VNC2 chips here. I expected them to be really useful - I mean, TWO USB Host controllers on one inexpensive general purpose 48pin chip! But the architecture is essentially undocumented, with the 'just use our SDK and libraries" argument. I found it terribly de-motivating :-(

author: SiliconWizard
author_rank: Super Contributor
timestamp: December 04, 2019, 03:04:41 pm
content: Quote from: westfw on December 04, 2019, 03:23:06 amNever used VNC2 chips. I can understand the frustration if you were looking for very specific information on internals, but there's still a large amount of documentation compared to many others ICs...https://www.ftdichip.com/Products/ICs/VNC2.htm

author: David Hess
author_rank: Super Contributor
timestamp: December 04, 2019, 05:13:32 pm
content: All of the ARM based microcontrollers which access their I/O ports over the low speed peripheral bus seem to have issues if you access the I/O port registers too quickly which makes sense but none of the documentation discusses it. Those who use libraries for this would never notice because of their low performance but it is an issue if you access the ports at a low level.

author: profdc9
author_rank: Frequent Contributor
timestamp: December 04, 2019, 06:34:22 pm
content: I haven't heard anyone mention the NXP LPC series yet. Is that because they aren't used that much?

author: David Hess
author_rank: Super Contributor
timestamp: December 04, 2019, 09:50:59 pm
content: Quote from: profdc9 on December 04, 2019, 06:34:22 pmThe NXP LPC series is actually where I first ran across the I/O port problems that I mentioned above.

author: ataradov
author_rank: Super Contributor
timestamp: December 05, 2019, 12:04:38 am
content: Quote from: David Hess on December 04, 2019, 05:13:32 pmWhat issues? I have never seen anything like that, and I'm not sure it makes any sense.

author: julianhigginson
author_rank: Frequent Contributor
timestamp: December 05, 2019, 02:00:39 am
content: Quote from: mark03 on August 22, 2019, 05:14:55 pmYeah... EFR32 was a shocker. I'd almost forgotten about that. The quoted sleep current was totally out - which is really fundamental for a little low power RFSOC... but as i remember it they didn't even correct the basic info sheets... the only place it was corrected was in the errata. I wonder how many people designed it into something for a first prototype without realising its sleep current was about 4x what they were expecting?

author: David Hess
author_rank: Super Contributor
timestamp: December 05, 2019, 02:47:13 pm
content: Quote from: ataradov on December 05, 2019, 12:04:38 amThe issue is that the ARM processor on these faster microcontrollers can issue transactions faster than the bus connecting the I/O ports can handle them. On the NXP ones where I first encountered the issue, this can leave the I/O port in an undefined state unless you include delays between accesses. If you were using library routines to access the I/O ports, then this problem never occurred because the libraries were so slow anyway.Later microcontrollers may have added logic to prevent this problem. Some moved the I/O ports to the faster ARM local bus.

author: Karel
author_rank: Super Contributor
timestamp: December 05, 2019, 03:22:00 pm
content: Quote from: David Hess on December 05, 2019, 02:47:13 pmIf you take a look at the HAL libraries, you see that STM solved this problem by reading back the same data like this:Code:volatile unsigned int tmp;tmp = some_gpio_register;...change some bits of tmp...some_gpio_register = tmp;tmp = some_gpio_register; /* read back the value */

author: westfw
author_rank: Super Contributor
timestamp: December 06, 2019, 06:08:37 am
content: QuoteIt looks like a lot, but it's particularly vacuous. I've gotten more info from the diagrams in untranslated Chinese data sheets :-(

author: SiliconWizard
author_rank: Super Contributor
timestamp: December 06, 2019, 03:11:38 pm
content: Quote from: Karel on December 05, 2019, 03:22:00 pmThe HAL for which STM32 line, and for which HAL function?I've taken a look at the STM32L4's HAL (which is the line I currently use the most), and the function for setting the state of an output (HAL_GPIO_WritePin) is just writing to either the BSRR or BRR register of the corresponding GPIO port, nothing else.

author: ajb
author_rank: Super Contributor
timestamp: December 06, 2019, 06:12:56 pm
content: STM32 have absolutely absurd pin mappings which always make it a huge pain and a big time sink to find an optimal set of pin assignments, and even so the best solution still often results in ridiculous routing (like QSPI on three or four sides of a QFP, MII lines in the middle of the ADC, etc). Their QSPI peripheral also has a really nasty hardware defect that will totally lock up the chip if two unrelated events occuron the same clock cycle, which makes it like the worst possible thing to debug.On the other side, I really love Atmel's SERCOM peripheral. Having one peripheral that can be SPI, UART, or I2C plus having a generous number of them per chip is really nice. It makes layout easier, and is especially handy when you have uncommitted pins you may want to use for future expansion, since you don't have to commit to a particular interface. I also like their GCLK system, it's a little clunky to set up but in the end it's easier to understand and more flexible than the fixed clock trees on a lot of other parts.

author: Yansi
author_rank: Super Contributor
timestamp: December 06, 2019, 07:51:08 pm
content: Quote from: SiliconWizard on December 06, 2019, 03:11:38 pmBut how's that related? There are none STM32 chips with GPIOs sitting on a bus slower than the CPU core, are there?

author: ataradov
author_rank: Super Contributor
timestamp: December 06, 2019, 07:53:32 pm
content: Yes, I don't get it. The only reason for this code would be to make sure that the state has really changed before the next instruction. This may be necessary for example for chip select before doing the SPI transfer. But there is no reason to put that into the generic GPIO code.Also, even on NXP, what exactly happens? How can GPIO be slower than the bus? This makes no sense to me.

author: Karel
author_rank: Super Contributor
timestamp: December 07, 2019, 07:51:01 am
content: Yes, I was mistaken. The code example is not related to toggling the GPIO pins.However, the example is all over the place in the HAL libraries to make sure that a setting has taken place before the next instruction takes place.In the HAL, this is done a lot when configuring the peripherals.I learned this the hard way when I started to write my own lowlevel drivers for STM32.To people complaining about the lack of code examples for STM32, CubeMX is the code example.Simply create a new project in CubeMX which uses the peripheral or feature you are interested in and let it generate the code which you canuse as an example or to study how to accomplish things.For example, I stumbled over a problem with an SPI peripheral of an STM32L4 not working and I went over the manuals many times butI couldn't understand what the problem was. Then I decided to have a look at the code generated by CubeMX and there I discovered thatit activated the SSOE option of the SPI peripheral (register CR2), even if you didn't enable it in the CubeMX configurator.So, I did the same (I didn't assign a pin to it though) and it started to work...

author: Silenos
author_rank: Regular Contributor
timestamp: December 07, 2019, 10:17:56 am
content: Quote from: ajb on December 06, 2019, 06:12:56 pmOh yes. I have QSPI, normal SPIs, LTDC with 20+ pins, all randomly and uniformly distributed on the 100 pin H7 package and board looks like cancer lump. Plus these H7 100 pin packages lack bonding of one red color line thus rendering LTDC 24 bit color space unable.This and that muss of routing full stack of high speed/flagship/analog peripherals onto the first ports, while the bigger packages route barely anything at extra ports. Yes, I guess things like ULPI or MII are nasty and does't allow for routing mux but god, just assign neigboring pins to each of them and just add to these pins mux for slower peripherals. And get it shooed with just adding clocking/function constraints like "you will get SPI1 clock: max 100 MHz on this muxed pin, max 10 MHz on that muxed ULPI pin, bootlading with SPI1 works only on these pins..."...And you tell me QSPI is inherently flawed? I used it in 'register access control' mode and yes, it was a invisible minefield of forbidden internal states which stepping into resulted in a total crash, but ultimately this thing is performing well. What is that "unrelated events occurance"?@GPIO driving: never seen loss of drive control at stm32 pin. Although I didnt really tried to push its toggling limits. I assumed that on thing like H7 (noticed that this family has slow access to ports) spinning 500 MHz and spam toggle, the bus io write transaction simply stall the core, as it is a generic high-latency-memory access instruction :-//m .This is my major issue for STM32 documentation. Microarchitecture details like above are banned in docs even though they are perfectly palpable. So be sure if my above assumption is correct I have to set up test unit, counting COUNT register and instructions, considering all the interferences and crap. Waste of time. Like STM/ARM couldn't just mention it in GPIO RM section. Same with core pipeline behaviour.Though afaik it applies to every vendor: incosistent writing and composition style among reference manual. There are chapters, like QSPI, PLL/RCC or LTDC which are mostly OK, logical, kept concised - they are acutally coherent with hardware and useful. Plus actually mostly useful AN.There are also things like Timers, where imo it is better to start from looking into registers description and core schematic than text description.Then there are things like USB core chapter - copy-pasted subsections with almost 10yo text, containing misguiding info, lacking actual info ("so what on earth is the pop address of that shared ram rx"), hidden registers, undocumented registers, plague of register accesses causing state switch (which eventually kills debugger usage), incoherent svd files, errors in svd files, useless register bits descriptions, hidden influences on ip core state, hidden time-influenced states...And on top on that everchanging ip core, even from silicon rev to rev, with changing critical default settings, closing to uselessness official usb docs, and everlooming ultimate enemy: windows usb drivers, always ready to plot a new way to collapse the stack and ruin the day.Imo it would be easier to just describe the ahb side of interface and for the rest reference Synopsys docs which afaik are, of course, off limits.

author: SiliconWizard
author_rank: Super Contributor
timestamp: December 07, 2019, 03:14:53 pm
content: Quote from: Karel on December 07, 2019, 07:51:01 amI believe you, but would you care to post at least an excerpt of it?Quote from: Karel on December 07, 2019, 07:51:01 amPeople complaining about that have probably never cared to take a look at what's inside the HAL directories? There are many examples for almost (but admittedly not quite all) all peripherals and CPU features ('Projects' subdirectory). And then, the full source code of HAL is also there and certainly helps figuring out all the functions available, what they do and their parameters. (Not saying that HAL is perfect, but that's not the point here.)There's no need to ever use CubeMX IMO - when I started with the STM32 MCUs, I started with the HAL, but I absolutely never installed or used the CubeMX software. The HAL files were certainly enough to get started IMO.

author: ajb
author_rank: Super Contributor
timestamp: December 07, 2019, 05:08:04 pm
content: Quote from: Silenos on December 07, 2019, 10:17:56 amDisclaimer: I'm still a bit bitter about the weeks of my life this problem cost me.If you run the QSPI in memory mapped mode with the low-power timeout enabled (deasserts the CS after a period of inactivity so that an external flash IC can switch to a lower power state), when the timeout expireson the same clock edgeas an attempt to read from the QSPI, the peripheral deadlocks and locks up the entire MCU. Even the debug interface stops working! Because this requires single-clock-cycle timing, it's sensitive to literally everything, making it really hard to isolate, and in my case I ran into it only after my project was quite far along and long after I'd implemented QSPI. The system would just lock up seemingly at random, anywhere from four times in an hour to not once in 24hrs, just depending on what changes I made to the code and on communications/interrupt timing. Attempting to use a debugger would either fail completely or just dump me back to the start of main(), which was a bonus headscratcher until I figured that out. Oh, and at the time, the hardware defect was not yet documented! Even now the errata entry is terribly blithe about the magnitude of the defect:Quote"Read operations fail", that's a bit of an understatementFortunately, the fix is as easy as disabling the timeout, which is a bit annoying for battery applications I guess, but manually managing the external flash power state is far better than the alternative.

author: brucehoult
author_rank: Super Contributor
timestamp: December 07, 2019, 07:34:42 pm
content: Quote from: ajb on December 07, 2019, 05:08:04 pmAnd if you started the access a cycle later than it's ok and wakes up the device again? That's nasty!

author: SiliconWizard
author_rank: Super Contributor
timestamp: December 11, 2019, 07:41:09 pm
content: Quote from: Yansi on December 06, 2019, 07:51:08 pmOops, missed that.Well, actually yes there are. They implement pretty much the same architecture as most Cortex-based MCUs I've seen (there may be exceptions, but haven't seen them myself), following the AMBA architecture. Peripherals, including GPIOs, are usually connected to one (or more) APB bus. There's one bridge per APB bus connecting to the AHB bus. APB busses are typically clocked with a separate, and often slower clock (programmable on many MCUs.) Some higher-performance MCUs have some of their peripherals (like Ethernet) directly connected to the AHB bus, but most still are just connected to an APB. Some MCUs also have their GPIOs directly connected to AHB instead. I can't tell off the top of my head which STM32 lines have their GPIOs on AHB and which on APB, but I'm pretty sure both approaches have been implemented.Edit: Took a deeper look to give more precise information. The STM32 series in which the GPIOs are on an APB bus is the famous F1 series (including the very popular F103). On other series, such as the more recent L4, GPIOs are on the AHB2 bus, which can be accessed faster than a typical APB, but AHB2 itself can be clocked at a lower speed than the CPU core. So synchronization issues are still potentially there (but would be due to a silicon bug).On older ARM-based (non-Cortex) MCUs not implementing this AMBA architecture (which I think dates back to early 2000's), that may have been a problem indeed, but I don't know of any current STM32 that doesn't?But it's still not completely impossible that some silicon bug in the AHB-APB bridges would require the use of workarounds (ot between the different AHB busses when there are several). I just haven't seen any myself in all STM32 (and most other Cortex-based) MCUs I've run into.

author: westfw
author_rank: Super Contributor
timestamp: December 12, 2019, 02:33:34 am
content: QuoteOr "in addition to", or even on some side channel. Atmel SAMx2x for example has GPIO pins available via a single-cycle "IOBUS" that is shown as directly connected to the CPU (at least, in the data sheet block diagrams.)

author: warpco
author_rank: Contributor
timestamp: December 12, 2019, 08:29:03 am
content: I've worked with PIC, LPC, STM32, TMS320, and with one ARM-based uC from Analog Devices. Documentation from Microchip always had many useful examples and step-by-step instructions on how to use periphery. I missed this in the other manufacturers' documentation.Regarding the hardware, I think there are no leaders, they are all more or less okay. For example, uC from Analog Devices had a very flexible and simple clocking scheme. I could set the multipliers/dividers individually for each periphery with just a few commands. But DMA configuration was much easer in one of the STM32 MCUs.

author: SiliconWizard
author_rank: Super Contributor
timestamp: December 12, 2019, 02:42:41 pm
content: Quote from: westfw on December 12, 2019, 02:33:34 amI admit I don't know the ATSAM MCUs and have never used them. Out of curiousity, I took a look at the SAMD21 family datasheet. Actually, they implement some kind of hybrid approach (quoting):QuoteSo the GPIOs are accessible both via this IOBUS bus, or via an APB bus. Later in the DS we can read:Quote

author: Harjit
author_rank: Regular Contributor
timestamp: December 12, 2019, 03:57:41 pm
content: Given the discussion on the STM32H7, an alternate part is NXP's iMXRT1064. From reading the specs and the errata, they've done a good job of keeping things clean and orthogonal.Also, the power consumption is incredibly low. This was a surprise since both the STM32H7 and the iMXRT1064 are implemented in a 40nm process.

author: MT
author_rank: Super Contributor
timestamp: December 12, 2019, 10:40:06 pm
content: Quote from: ajb on December 07, 2019, 05:08:04 pmOK, so this lockup only applies to QSPI when "low-power timeout enabled" else it performs OK for mem mapped modein all BNK modes?Quote from: ajb on December 06, 2019, 06:12:56 pmDoes this lockup apply to all ST QSPI enabled devices and all BNK modes? Even H7? ! QSPI BNK2 on F446 and H750 only NSC comes from the opposite side (non ADC) rest is neatly pin by pin on one side.

author: ajb
author_rank: Super Contributor
timestamp: December 12, 2019, 11:04:09 pm
content: Quote from: MT on December 12, 2019, 10:40:06 pmThat is correct as far as I know.Quote from: MT on December 12, 2019, 10:40:06 pmPresumably every part that shares the same QSPI peripheral revision. I've tested it personally on F777 and F746. It's actually pretty easy to test, you don't even need to have an external flash IC connected:- Setup the QSPI peripheral in memory mapped mode with the timeout counter enabled- Create a short spin loop to periodically read from some address in the QSPI range- Sweep the timeout counter register valueYou can twiddle an IO pin and scope it along with the QSPI nCS line to watch the correlation (and know immediately when it locks up)Here's the minimal test program I threw together to demo the problem. It's mostly defines used in configuration, the actual demonstration is only a few lines.Code:/** The following is a minimal demonstration of an apparent problem with* the QUADSPI peripheral on STM32F7 parts. The QUADSPI seems to totally* lock up the MCU--even preventing debugging--under the following conditions:* - The QUADSPI is in memory mapped mode* - The QUADSPI's timeout counter is enabled* - The timeout counter expires, releasing the QUADSPI_NCS line, right about*the time that a memory-mapped QUADSPI access is attempted.** This program has been run on a Nucleo-F767ZI board and successfully* demonstrated the problem. It does not require that an external IC be* connected to the QUADSPI interface. It should run on similar parts with* no modification.** Be aware that the nature of this apparent fault makes the program rather* delicate with regard to timing. It has been successful when compiled* without optimization. It would probably be more reliable if the main test* loop were written in assembly, but even so the run-time performance* optimizations of the Cortex-M7 may introduce sufficient timing variations* that it takes several tries to achieve the timing required to cause the* fault.**//* Includes */#include "stm32f7xx.h"/* ***************************************************************************** QUADSPI CONFIG VALUES* ****************************************************************************/#define QUADSPI_DCR_FSIZE_Pos16#define QUADSPI_CR_PRESCALER_Pos24#define QUADSPI_DCR_CSHT_Pos8/* QUADSPI->CCR.FMODE specifies the functional mode */#define QUADSPI_CCR_FMODE_gp26#define QUADSPI_CCR_FMODE_MEMMAP(3<<QUADSPI_CCR_FMODE_gp)/* QUADSPI->CCR.DMODE specifies the number of IO lines to use for* data transfer */#define QUADSPI_CCR_DMODE_gp24#define QUADSPI_CCR_DMODE_SINGLE(1<<QUADSPI_CCR_DMODE_gp)/* QUADSPI->CCR.DCYC specifies the number of dummy cycles to insert between* the address and data phases of the transaction */#define QUADSPI_CCR_DCYC_gp18#define QUADSPI_CCR_DCYC_gm(0x1f<<QUADSPI_CCR_DCYC_gp)#define QUADSPI_CCR_DCYC_m(num)((num<<QUADSPI_CCR_DCYC_gp) & QUADSPI_CCR_DCYC_gm)/* QUADSPI->CCR.ABMODE specifies the number of IO lines to use for* alternate byte transfer */#define QUADSPI_CCR_ABMODE_gp14#define QUADSPI_CCR_ABMODE_NONE(0x0<<QUADSPI_CCR_ABMODE_gp)/* QUADSPI->CCR.ADSIZE specifies the number of address bits to use */#define QUADSPI_CCR_ADSIZE_gp12#define QUADSPI_CCR_ADSIZE_24BIT(0x2<<QUADSPI_CCR_ADSIZE_gp)/* QUADSPI->CCR.ADMODE specifies the number of IO lines to use for* address transfer */#define QUADSPI_CCR_ADMODE_gp10#define QUADSPI_CCR_ADMODE_gm(0x3<<QUADSPI_CCR_ADMODE_gp)#define QUADSPI_CCR_ADMODE_SINGLE(0x1<<QUADSPI_CCR_ADMODE_gp)/* QUADSPI->CCR.DMODE specifies the number of IO lines to use for* instruction transfer */#define QUADSPI_CCR_IMODE_gp8#define QUADSPI_CCR_IMODE_gm(0x3<<QUADSPI_CCR_IMODE_gp)#define QUADSPI_CCR_IMODE_SINGLE(0x1<<QUADSPI_CCR_IMODE_gp)#define QSPI_CCR_MEMMAP_VAL(QUADSPI_CCR_FMODE_MEMMAP |\QUADSPI_CCR_DMODE_SINGLE |\QUADSPI_CCR_DCYC_m(0)|\QUADSPI_CCR_ABMODE_NONE |\QUADSPI_CCR_ADSIZE_24BIT |\QUADSPI_CCR_ADMODE_SINGLE |\QUADSPI_CCR_IMODE_SINGLE |\EXTFLASH_CMD_READ)#define EXTFLASH_CMD_READ0x03/* ***************************************************************************** GPIO CONFIG MACROS* ****************************************************************************/#define IO_OUTSET(...)/* set (port, pin) output */IO_OUTSET_SUB(__VA_ARGS__)#define IO_OUTSET_SUB(port, pin)GPIO##port->BSRR = (1<<pin)#define IO_OUTCLR_SUB(port, pin)GPIO##port->BSRR = ((1<<pin)<<16)#define IO_OUTCLR(...)/* clear (port, pin) output */IO_OUTCLR_SUB(__VA_ARGS__)#define IO_OUTTGL(...)/* toggle (port, pin) output */IO_OUTTGL_SUB(__VA_ARGS__)#define IO_OUTTGL_SUB(port, pin)GPIO##port->ODR = (GPIO##port->ODR ^ (1<<pin));#define IO_DIROUT(...)/* set (port, pin) as output */IO_DIROUT_SUB(__VA_ARGS__)#define IO_DIROUT_SUB(port, pin)IO_SET_MODE(port,pin, IO_MODER_OUTPUT_gv)#define IO_SET_MODE(...)IO_SET_MODE_SUB(__VA_ARGS__)#define IO_SET_MODE_SUB(gpio, pin, mode_gv)GPIO##gpio->MODER = ((GPIO##gpio->MODER & ~IO_MODER_gm(pin)) | ((mode_gv << (pin*2))&IO_MODER_gm(pin)))#define IO_MODER_gm(pinNum)(0x03<<(2*pinNum))#define IO_MODER_INPUT_gv0x00#define IO_MODER_OUTPUT_gv0x01#define IO_MODER_ALT_gv0x02#define IO_MODER_ANALOG_gv0x03#define IO_AF_SEL(...) IO_AF_SEL_SUB(__VA_ARGS__)#define IO_AF_SEL_SUB(gpio, pin, af_gv)IO_AF_SEL_PIN##pin(gpio, pin, af_gv)#define IO_AF_SEL_PIN0(...)IO_AF_SEL_SUB_LO(__VA_ARGS__)#define IO_AF_SEL_PIN1(...)IO_AF_SEL_SUB_LO(__VA_ARGS__)#define IO_AF_SEL_PIN2(...)IO_AF_SEL_SUB_LO(__VA_ARGS__)#define IO_AF_SEL_PIN3(...)IO_AF_SEL_SUB_LO(__VA_ARGS__)#define IO_AF_SEL_PIN4(...)IO_AF_SEL_SUB_LO(__VA_ARGS__)#define IO_AF_SEL_PIN5(...)IO_AF_SEL_SUB_LO(__VA_ARGS__)#define IO_AF_SEL_PIN6(...)IO_AF_SEL_SUB_LO(__VA_ARGS__)#define IO_AF_SEL_PIN7(...)IO_AF_SEL_SUB_LO(__VA_ARGS__)#define IO_AF_SEL_PIN8(...)IO_AF_SEL_SUB_HI(__VA_ARGS__)#define IO_AF_SEL_PIN9(...)IO_AF_SEL_SUB_HI(__VA_ARGS__)#define IO_AF_SEL_PIN10(...)IO_AF_SEL_SUB_HI(__VA_ARGS__)#define IO_AF_SEL_PIN11(...)IO_AF_SEL_SUB_HI(__VA_ARGS__)#define IO_AF_SEL_PIN12(...)IO_AF_SEL_SUB_HI(__VA_ARGS__)#define IO_AF_SEL_PIN13(...)IO_AF_SEL_SUB_HI(__VA_ARGS__)#define IO_AF_SEL_PIN14(...)IO_AF_SEL_SUB_HI(__VA_ARGS__)#define IO_AF_SEL_PIN15(...)IO_AF_SEL_SUB_HI(__VA_ARGS__)#define IO_AF_SEL_SUB_HI(gpio, pin, af_gv) GPIO##gpio->AFR = ((GPIO##gpio->AFR & ~IO_AFRH_gm(pin)) | ((af_gv << ((pin-8)*4)) & IO_AFRH_gm(pin)));#define IO_AF_SEL_SUB_LO(gpio, pin, af_gv) GPIO##gpio->AFR = ((GPIO##gpio->AFR & ~IO_AFRL_gm(pin)) | ((af_gv << (pin*4)) & IO_AFRL_gm(pin)));#define IO_AFRL_gm(pinNum) (0x0f<<(pinNum*4))#define IO_AFRH_gm(pinNum) (0x0f<<((pinNum-8)*4))/* ***************************************************************************** GPIOS IN USE* ****************************************************************************/#define LED1B,0 //GREEN#define LED2B,7//BLUE#define LED3B,14 //RED#define QUADSPI_CLKF,10#define QUADSPI_NCSB,6#define QUADSPI_CLK_AF9#define QUADSPI_NCS_AF10/* Private macro *//* Private variables *//* Private function prototypes *//* Private functions */void QSPI_memMapMode(void);void QSPI_memMapModeDisable(void);void QSPI_init(void){IO_SET_MODE(QUADSPI_CLK, IO_MODER_ALT_gv);IO_SET_MODE(QUADSPI_NCS, IO_MODER_ALT_gv);IO_AF_SEL(QUADSPI_CLK, QUADSPI_CLK_AF);IO_AF_SEL(QUADSPI_NCS, QUADSPI_NCS_AF);RCC->AHB3ENR |= RCC_AHB3ENR_QSPIEN;// clk = AHB, using bank 1QUADSPI->CR = 0<<QUADSPI_CR_PRESCALER_Pos | 0;/** vvvv This is the problem vvvv ******************************************/QUADSPI->CR |= QUADSPI_CR_TCEN; // enable timeout in memory mapped mode/** ^^^^ This is the problem ^^^^ ******************************************/QUADSPI->DCR =( 23 << QUADSPI_DCR_FSIZE_Pos ) | // 23-bit addressing = 8MB( 7<< QUADSPI_DCR_CSHT_Pos); // 7 -> 8 clock cycles of nCS high between commandsQUADSPI->CR |= QUADSPI_CR_EN;QUADSPI->FCR =QUADSPI_FCR_CTEF |QUADSPI_FCR_CTCF |QUADSPI_FCR_CSMF |QUADSPI_FCR_CTOF;QUADSPI->DLR = 0;QUADSPI->LPTR = 0;//Configure QSPI for memory-mapped modeQSPI_memMapMode();}void QSPI_memMapMode(void){QUADSPI->CCR = QSPI_CCR_MEMMAP_VAL;}void QSPI_memMapModeDisable(void){QUADSPI->CCR = 0;QUADSPI->CR |= QUADSPI_CR_ABORT;while(QUADSPI->CR & QUADSPI_CR_ABORT);}uint32_t delay_time=10;volatile uint8_t dummyval;volatile uint8_t * exfl = (uint8_t*)(0x90000000);uint16_t offs=0;int main(void){RCC->AHB1ENR |= RCC_AHB1ENR_GPIOBEN | RCC_AHB1ENR_GPIOFEN;IO_DIROUT(LED1);IO_DIROUT(LED2);IO_DIROUT(LED3);/* configure SWO pin (optional -- since the MCU will* wind up in a state where debugging is impossible,* the only way to extract the parameters that trigger* the fault is to capture that data beforehand).*/IO_SET_MODE(B,3,IO_MODER_ALT_gv);IO_AF_SEL(B,3, 0);QSPI_init();while (1){for(uint32_t i=0; i<500; i++){/* many reads are made at each timing step to* increase the chances of the fault occurring, since* it is so sensitive to timing.*/IO_OUTSET(LED3);for(uint32_t j=0; j < delay_time; j++);IO_OUTCLR(LED3);dummyval = *(exfl+(offs++));}IO_OUTSET(LED2);if( (delay_time % 100) ==0) IO_OUTTGL(LED1);//delay_time+=1;QSPI_memMapModeDisable();/* sweeping the QSPI timeout works better than sweeping* delay_time because the timer (running at AHB frequency)* has better granularity than a C spinlopp, therefore the* chances of the timing lining up to cause the fault are* much improved.*/QUADSPI->LPTR++;QSPI_memMapMode();IO_OUTCLR(LED2);}}

author: MT
author_rank: Super Contributor
timestamp: December 12, 2019, 11:18:08 pm
content: Quote from: ajb on December 12, 2019, 11:04:09 pmThanks for the heads up, appreciated , this is a serious issue for batt apps , hope its gone with the H750 rev V thats coming in Januari 2020. Will try your code on the F446 and see whats happens..

author: jesuscf
author_rank: Frequent Contributor
timestamp: December 13, 2019, 05:35:25 pm
content: Some Nuvoton microcontrollers have interesting sections in their documentation. For example:http://www.nuvoton.com/resource-files/DS_N76E003_EN_Rev1.06.pdf"IAP facilitates the updating flash contents in a convenient way; however, user should follow some restricted laws in order that the IAP operates correctly. Without noticing warnings will possible cause undetermined results even serious damages of devices. Furthermore, this paragraph will also support useful suggestions during IAP procedures.""In general application, there is a need of data storage, which is non-volatile so that it remains its content even after the power is off. Therefore, in general application user can read back or update the data, which rules as parameters or constants for system control.""Note: When register CKDIV value is not equal 00H, the system clock frequency will be divided, if under this condition after MCU into power down mode, the WDT Reset will fail. So suggest use WKT to wakeup N76E003 when into power down mode."