Being trolled by STMicroelectronics

[Psi]

Being trolled by STMicroelectronics engineers in the LIS2DE12 Accelerometer datasheet.
http://www.st.com/resource/en/datasheet/lis2de12.pdf

[ataradov]

A bit like this exists in a lot of Atmel/Microchip devices as well.

Just some setting that was supposed to be optional, but was determined to be mandatory.

[Dubbie]

Ha!

I just wrote a driver for that chip the other week. I also chuckled at that line.

[xaxaxa]

well if you work with stm32s often you know they are all full of gotchas; forgot to enable RCC_AFIO? some of your peripherals just don't work and you don't know why. Enabled your adc on a stm32f1 and suddenly uart stops working? oh you have to look through the entire pin remapping table and make sure no peripherals share the same pins. I don't even know why the pin mapping on the stm32f1 is peripheral-based rather than pin-based like the stm32f0. Last time I still haven't managed to get usart receive working even though I've double checked all the registers I can think of - I can see the uart waveform on
the RX pin but the receiver on the stm32 just never reports anything.

I will never use an stm32 in any mission critical devices for the simple reason it violates the "no surprises" principle EVERYWHERE.

[ataradov]

Everything is a surprise in a new device. All new devices I've worked with (excluding members of the same family) from different manufacturers had something initially strange in them.

With principles like that you will never use anything more complicated than a resistor. Or devices you already know and got used to all the quirks.

[xaxaxa]

I haven't had that experience with atmel or TI microcontrollers or even the esp8266; i don't know but it just seems to me that everything in stm32 is designed to be confusing; something that takes me a few minutes to get working on any other platform takes hours of debugging on stm32; not even the gpios can be trusted and I end up having to poke the pins with a multimeter just to make sure the gpios are even outputting what I want them to output.

Even learning fpga development was far easier and more straightforward; when I set a gpio to mode output and drive the signal with a '1' I *know* for sure that the pin is now high, provided the pcb design isn't messed up. In stm32f1 you potentially need to do something different for every pin; for example the pin named "PB4" does NOT power up as "PB4"; you have to set something in the jtag controller registers to get that pin to be a gpio. Arguably this is a pin naming issue but it was still a big surprise on something supposed to be simple.

[Jeroen3]

for example the pin named "PB4" does NOT power up as "PB4"; you have to set something in the jtag controller registers to get that pin to be a gpio. Arguably this is a pin naming issue but it was still a big surprise on something supposed to be simple.

Not the JTAG controller, the alternate function multiplexer (AFIO). Older parts just say "this pin is NJTRST". With modern 32 bitters you can choose to use it for GPIO if you have SWD and don't need JTAG, but you need it during reset to program it so it defaults to JTAG  . Looks like you're just ranting on it being a modern part you don't understand yet.

Just remember, it is hard to write good documentation. And we can't yet transfer memories with BrainLink™, so you'd have to do it with PDFs for now.

[ataradov]

Well, we are two for two. On Microchip SAM V7x pin PB4 also powers up as one of the JTAG pins and needs to be disables to be used as GPIO

If I were stressing like this over all minor inconveniences in the MCUs, I'd have grey hair by now.

[JPortici]

it just seems to me that everything in stm32 is designed to be confusing;

pretty much, yeah

Anyway, we had one product that changed from the dsPIC(don't remember which exactly) to its "A" version (may have been dsPIC33FJ256GP708A)
the first release went out of production and since then we had intermittent issues with the canbus.
i then went looking at the datasheets, checking registers while debugging and i noticed that an undocumented bit was 1 in the previous release, 0 in the current release.
Set the bit at startup, no more faults since then.

I think it i also saw it in the errata

[Jeroen3]

If I were stressing like this over all minor inconveniences in the MCUs, I'd have grey hair by now.

No hair would be more accurate I think. You'd have pulled it all out.

[T3sl4co1l]

Everything is a surprise in a new device. All new devices I've worked with (excluding members of the same family) from different manufacturers had something initially strange in them.

With principles like that you will never use anything more complicated than a resistor. Or devices you already know and got used to all the quirks.

Hey, Z80s in DIP40, PLCC44 and so on are still readily available (if nowhere near competitive with modern ARMs and such, let alone in terms of power).

Tim

[xaxaxa]

well suppose I'm implementing the WIRING api pinMode() function; I'd have to special-case those pins since there is no universal way to say "set this pin to gpio mode no matter what alternative functions are available on it"; it's even worse if i want to support analog pinMode, since I don't know what other functions may be on each adc-supported pin and I'd have to hard code a table for every device variant, then have some complex logic to go through each possible alternate function and either set the right remap bits or disable that peripheral. What if i want to remap only usart rx? that's not possible because setting the remap bit remaps the entire peripheral.

The stm32f0 doesn't have this problem but that begs the question - why are even the gpio facilities different between f0 and f1? I have a lot of library code that I want to work with both f0 and f1, and I prefer to avoid special casing as much as possible.

[ataradov]

well suppose I'm implementing the WIRING api pinMode() function; I'd have to special-case those pins since there is no universal way to say "set this pin to gpio mode no matter what alternative functions are available on it";

No, you just disable overriding functions in the startup code.

The stm32f0 doesn't have this problem but that begs the question - why are even the gpio facilities different between f0 and f1? I have a lot of library code that I want to work with both f0 and f1, and I prefer to avoid special casing as much as possible.

Because sometimes you learn new things and use cased as you use the device, and it makes sense to address those issues in the newer designs. Otherwise you are stuck with original bad design.

[Jeroen3]

What if i want to remap only usart rx?

You can't. Improvise. Adapt. Overcome.

[T3sl4co1l]

Because sometimes you learn new things and use cased as you use the device, and it makes sense to address those issues in the newer designs. Otherwise you are stuck with original bad design.

Or you do a Microchip and just keep adding bad to worse.

Anyone ever used PIC24?  I've heard horror stories...

Tim

[Yansi]

Well sorry guys, nothing new.

Any larger 32bit MCU is full of registers, with undocumented bits and bytes, that in some cases need to be cared of: Typically: "leave these reserved bits at reset value" or such.

A single LPen bit in the accelerometer is still nothing compared to the Silabs EZRadioPro devices. There are some registers that contain invalid values after reset and these needs to be rewritten by the user. But you will never find out, unless you read through all of these like 200+ registers descripttion! Jeez... I was pissed.

[Yansi]

The stm32f0 doesn't have this problem but that begs the question - why are even the gpio facilities different between f0 and f1? I have a lot of library code that I want to work with both f0 and f1, and I prefer to avoid special casing as much as possible.

Jeeez. You haven't worked with STM32 much, have you? STM32F1 is an really old series made back then when the Cortex M started. The pin mappin and reampping feature was garbage and was abandoned and replaced by the more freindly AF multimplexers such as the F0 has. You should not be bitchin about, you should be glad that was abandoned!

[Dubbie]

I would never choose an F1 chip.
I always choose between an F0 or F4 for my projects.

Because I am an amateur, I use cubeMX to plan out my pin usage and generate the init code. Haven’t run into any problems yet with that method, but that may be because I don’t know what I don’t know.

[fourtytwo42]

Or you do a Microchip and just keep adding bad to worse.

Anyone ever used PIC24?  I've heard horror stories...

Tim

Meeahhhh  I decided self flagulation was not enough and not drawing enough blood so I went for PIC24EP AND used many features in it's high speed PWM!!! The medicine is definetly working, there is blood all over the workbench 

[fourtytwo42]

I would never choose an F1 chip.
I always choose between an F0 or F4 for my projects.

Because I am an amateur, I use cubeMX to plan out my pin usage and generate the init code. Haven’t run into any problems yet with that method, but that may be because I don’t know what I don’t know.

It depends what peripherals you want, if you need a lot of analogue F3 is the best IMOP But sadly as I found there pwm is a bit deficient

[xaxaxa]

Jeeez. You haven't worked with STM32 much, have you? STM32F1 is an really old series made back then when the Cortex M started. The pin mappin and reampping feature was garbage and was abandoned and replaced by the more freindly AF multimplexers such as the F0 has. You should not be bitchin about, you should be glad that was abandoned!

oh I thought stm32f1 was newer than f0. That clears it up, thanks; yes the f0 has much more sane pin remapping.

I only got on the stm32 bandwagon because the stm32f103 is really cheap, has usb, and really good "bang for the buck" in terms of processing power and ram... Only the f1 and f0 are reasonably priced (~$1), so I guess my only choice in stm32 left is f0 then.

[madires]

Bonus points for Chinglish, contradicting statements and commands/registers lost in space. You'll love datasheets for LCD controllers.

[Yansi]

LCD controller datasheet are still nothing compared to touch screen controllers, I mean those capacitive ones! We are currently developing something with a lovely 480x800 panel with a CTP. The LCD controller was indeed pain in the butt (ILI9806E), it required a ton of registers to be filled with settings, that all pretty much depend on the exact HW workings of the panel itself! Despite the fact the panel is chinese (Startek/Shenzen), the chinese guys were pretty helpful after we wrote them. They were only baffled where did we get those panels (Taobao).
The CTP controller was an another one. The display came wit the CTP already glued on and we didn't know anything about it, apart from the controller type and pinout. The same was needed: A metric shitton of registers, specific to the HW of the CTP. Doh! We couldn't figure that out, without the CTP datasheet. Fortunatelly - my friend found that these registers in the CTP controller are non-volatile, already written by the manufacturer. That saved the whole project!

Jeeez. You haven't worked with STM32 much, have you? STM32F1 is an really old series made back then when the Cortex M started. The pin mappin and reampping feature was garbage and was abandoned and replaced by the more freindly AF multimplexers such as the F0 has. You should not be bitchin about, you should be glad that was abandoned!

oh I thought stm32f1 was newer than f0. That clears it up, thanks; yes the f0 has much more sane pin remapping.

I only got on the stm32 bandwagon because the stm32f103 is really cheap, has usb, and really good "bang for the buck" in terms of processing power and ram... Only the f1 and f0 are reasonably priced (~$1), so I guess my only choice in stm32 left is f0 then.

All other series use the AF multiplexers, only F1 has those annoying remap features.

You may want to have a look at L0 series too, when looking for very cheap ones like L011. The F3 series also has a very good ratio of bang for a buck, as these are quite not as popular as they should.

[JPortici]

I think it i also saw it in the errata

found it: dsPIC33EPFJ128GP706A

ECAN  module  may  not  transmit  Buffer  0  data  if Buffer 1 data is queued for transmission first. This problem is specific to transmit Buffers 0 and 1 only.
Work around:
The issue can be fixed by setting reserved bit 11 in CiCTRL1 register to 1.
Note that the module reset value for this bit is zero.

 

Anyone ever used PIC24?  I've heard horror stories...

once. in high school. PIC24FV KA series. i tried many times without success to use that idiotic ADC.
if anybody asks i'll rather use a PIC18 K42 thank you very much

dsPIC33E are more than fine though

[TassiloH]

I guess one will find stuff like that in most complex devices:

I've recently ported an USB CDC device library to add support for the STM32F7 controller series (before it was only for STM32F4). I read the migration guide "not software compatible". Hm. Looked at the reference manual and thought: "Well, looks pretty similar, I can make this work without many code changes". I found the differences in VBus detection settings etc, but it still wouldn't work, just no device visible to the host.

Many hours later I found the reason (basically by reading every register with the debugger and comparing between F4 and F7): The SDIS bit in the DCTL register. Same functionality on both controllers (that is why I missed it before), but the state after reset is different (on STM32F407, session/D+ pull-up is enabled after reset, on STM32F767, it is not). I just didn't see the difference in the Hex number which is given as reset state

(I am basically posting this so that google can find it, so someone running into the same problem can save some time)