How to convert STM32 snippet (code examples) written for target device STM32F072B to STM32F030r8 - arm

Dears,
I am newbie in embedded systems.
I have downloaded code examples from st.com written for target device STM32F072B. As I am using Nucleo-64 with STM32F030r8 MCU, I need to convert the downloaded code examples to support my target device STM32F030r8.
I can build the code examples (written for STM32F072B) in Keil, but when I am changing the target device to STM32F030r8 I am getting an error:
..\system_stm32f0xx.c(301): error: #20: identifier "RCC_CFGR_PLLSRC_HSI48_PREDIV" is undefined
Please help me either by telling the way to convert the downloaded code examples to support my target device STM32F030r8.
Regards
Niyas

Welcome to the exciting world of embedded systems where peripherals even change within sub-families of devices.
The missing macro your compiler complains about is actually a pretty good hint on whats wrong. Looking at the STM32F072B reference manual ST lists the following available clock sources:
Various clock sources can be used to drive the system clock
(SYSCLK):
HSI 8 MHz RC oscillator clock
HSE oscillator clock
PLL clock
HSI48 48 MHz RC oscillator clock (available on STM32F04x, STM32F07x and STM32F09x devices only)
Comparing that to the STM32F030 reference manual we can see that the HSI48 clock is clearly missing on this device.
Various clock sources can be used to drive the system clock
(SYSCLK):
HSI 8 MHz RC oscillator clock
HSE oscillator clock
PLL clock
I guess that some part of the code snippet you downloaded tries to use that missing HSI48 clock somehow. Switching the device inside the IDE most likely caused your project to use another device header where the macro "RCC_CFGR_PLLSRC_HSI48_PREDIV" simply isn't defined. You might be able to use another clock source instead, but your question doesn't contain enough information to answer that for certain.
Generally when working with embedded devices you have to be very careful when switching from one microcontroller to another. Even the tiniest differences (even a single register or a single bit) can break your build or even worse your hardware.

Thank-you Dears,
I found the answer. Guillaume Petitjean 's reply made me to read more documents and finally I made it.
Question:
The STM32SnippetsF0 (C-code examples) downloaded from https://www.st.com/en/embedded-software/stm32snippetsf0.html#overview is designed to run on the STM32F072B Discovery board. So changing target device(my case STM32F030r8) need many changes like adding supported header files etc.
*I got the mentioned error previously because I compiled simply after changing target device in setting but without adding proper header file. :(
*I was asking this. Don't know whether I asked properly. Anyway the solution i found is sharing with you all.
Answer:
This document tells how the snippet code can be used on other target device
https://www.st.com/resource/en/data_brief/stm32snippetsf0.pdf
After reading the document and adding necessary driver header files I am able to compile and build the code

Related

STM32 F407VG Boot into different (main-)applications

For a project I just started working on, I need to write a firmware in C that lets me boot into two different firmware versions. The task is to be able to update a device which includes an STM in the field using the RS485 Port with an Intel .hex file. My idea was to place the two firmware versions at designated starting addresses in the flash, including some kind of checksum for data integrity. According to the flash module organization found in the reference manual, my first thought was to place one version into sector 10 (starting at 0x080C0000) and the other version into sector 11 (starting at 0x080E0000). After every reset, the STM32 should boot into a "bootmanager" which is just minimum code that decides, whether the firmware in sector 10 or sector 11 is the newer version. I want to clarify my idea in the following graphic:
[Rough process][1]
[1]: https://i.stack.imgur.com/xLowh.png
The 128kBytes of every sector are sufficient. So far, I was able to write Single Bytes into the Flash and read them afterwards. Also, I have already set up a working UART communication using the RS485.
My questions
Can I just write the .hex file into the Flash as it is without modification like
:020000040800F2
:1000000002200B
etc?
As I am unexperienced with with jumps: How should I perform the jump from the "bootmanager" into sector 5 firmware? Are the adresses automatically relative to the entry point in sector 5?
Can you give me keywords or tell me, what challenges I will encounter?
*EDIT: I'm aware that the STM itself contains a bootloader. Unluckily, the RS485 device is hardwired to the GPIO pins used by USART2. According to the reference manual, the internal bootloader can only be used by USART1 and USART3, CAN2 and USB OTG FS
Can I just write the .hex file into the Flash as it is without
modification like
no you cant. You need to modify the linker script to archive it
You need to have the whole both applications in the FLASH so divide it 50/50%.
I usually add some serial FLASH to have a copy of the firmware if both of the images are damaged.
Yuo need to write the custom bootloader.
Most of the STM32 microcontrollers have support for dual memory bank and on the fly update (cf AN4767 - On-the-fly firmware update for dual bank STM32 microcontrollers)
This will allow to perform exactly what you require.
Usually the microcontroller will need to have a bootloader and 2 banks for the image.
When booting the bootloader will start and check which version it would have to boot and set the start address accordinngly.
This application note is for the F7 series but you can check it to see how it could work for your specific microcontroller (cf AN4826 - STM32F7 Series Flash memory dual bank mode).
Regarding your questions:
The code would be written as usual but twice (or 2 different firmwares)
Look into the application notes referenced and keywords such as: dual bank, on-the-fly update, DFU, etc

What is name of the timer/counter overflow interrupt in stm32

I am using timer in input capture mode in STM32 micro with keil compiler, and I want to trigger an interrupt whenever counter register of the dedicated timer overflows.
Could anyone please tell me how i can do that? what is the name of this interrupt?
Note: I am using hal functions.
Please check out the (exact) controller type you are using on the STM homepage (you can start from here:
https://www.st.com/en/microcontrollers-microprocessors/stm32-32-bit-arm-cortex-mcus.html
On the product page for your controller, you'll find a useful list of PDFs under "Resources", especially
the Reference Manual (find the register descriptions in the TIM description of the timer you use)
a list of Application Notes, which are relevant for all STM32 families, especially
AN4776
General-purpose timer cookbook for STM32 microcontrollers
https://www.st.com/resource/en/application_note/dm00236305-generalpurpose-timer-cookbook-for-stm32-microcontrollers-stmicroelectronics.pdf
and
AN4013
STM32 cross-series timer overview
https://www.st.com/resource/en/application_note/dm00042534-stm32-crossseries-timer-overview-stmicroelectronics.pdf
Looking for the correct library functions, you can use STM32CubeMX to configure the timers in a GUI and have the correct driver codes generated for you.
Good luck!

Writing device library C/C++ for STM32 or ARM

I need to develop device libraries like uBlox, IMUs, BLE, ecc.. from scratch (almost). Is there any doc or tutorial that can help me?
Question is, how to write a device library using C/C++ (Arduino style if you want) given a datasheet and a platform like STM32 or other ARMs?
Thanks so much
I've tried to read device libraries from Arduino library and various Github, but I would like to have a guide/template to follow (general rules) to write proper device libraries from a given datasheet.
I'm not asking a full definitive guide, just where to start, docs, methods approach.
I've found this one below, but is very basic and quite lite for my targets.
http://blog.atollic.com/device-driver-development-the-ultimate-guide-for-embedded-system-developers
I don't think that you can actually write libraries for STM32 in Arduino style. Most Arduino libraries you can find in the wild promote ease of usage rather than performance. For example, a simple library designed for a specific sensor works well if reading the sensor and reporting the results via serial port is the only thing that firmware must do. When you work on more complex projects where uC has lots to do and satisfy some real time constraints, the general Arduino approach doesn't solve your problems.
The problem with STM32 library development is the complex connection between peripherals, DMA and interrupts. I code them in register level without using the Cube framework and I often find myself digging the reference manual for tables that shows the connections between DMA channels or things like timer master-slave relations. Some peripherals (timers mostly) work similar but each one of them has small differences. It makes development of a hardware library that fits all scenarios practically impossible.
The tasks you need to accomplish are also more complex in STM32 projects. For example, in one of my projects, I fool SPI with a dummy/fake DMA transfer triggered by a timer, so that it can generate periodic 8-pulse trains from its clock pin (data pins are unused). No library can provide you this kind of flexibility.
Still, I believe not all is lost. I think it may be possible to build an hardware abstraction layer (HAL, but not The HAL by ST). So, it's possible to create useful libraries if you can abstract them from the hardware. A USB library can be a good example for this approach, as the STM32 devices have ~3 different USB peripheral hardware variations and it makes sense to write a separate HAL for each one of them. The upper application layer however can be the same.
Maybe that was the reason why ST created Cube framework. But as you know, Cube relies on external code generation tools which are aware of the hardware of each device. So, some of the work can be avoided in runtime. You can't achieve the same result when you write your own libraries unless you also design a similar external code generation tool. And also, the code Cube generates is bloated in most cases. You trade development time for runtime performance and code space.
I assume you will be using a cross toolchain on some platform like Linux, and that the cross toolchain is compatible with some method to load object code on the target CPU. I also assume that you already have a working STM32 board that is documented well enough to figure out how the sensors will connect to the board or to the CPU.
First, you should define what your library is supposed to provide. This part is usually surprisingly difficult. It’s a bit hard to know what it can provide, without knowing a bit about what the hardware sensors are capable of providing. Some iteration on the requirements is expected.
You will need to have access to the documentation for the sensors, usually in the form of the manufacturer’s data sheets. Using the datasheet, and knowing how the device is connected to the target CPU/board, you will need to access the STM32 peripherals that comprise the interface to the sensors. Back to the datasheets, this time for the STM32, to see how to access its peripheral interfaces. That might be simple GPIO bits and bytes, or might be how to use built-in peripherals such as SPI or I2C.
The datasheets for the sensors will detail a bunch of registers, describing the meaning of each, including the meanings of each bit, or group of bits, in certain registers. You will write code in C that accesses the STM32 peripherals, and those peripherals will access the sensors across the electrical interface that is part of the STM32 board.
The workflow usually starts out by writing to a register or three to see if there is some identifiable effect. For example, if you are exercising a digital IO port, you might wire up an LED to see if you can turn it on or off, or a switch to see if you can correctly read its state. This establishes that your code can poke or peek at IO using register level access. There may be existing helper functions to do this work as part of the cross toolchain. Or you might have to develop your own, using pointer indirection to access memory mapped IO. Or there might be specially instructions needed that can only be accessed from inline assembler code. This answer is generic as I don’t know the specifics of the STM32 processor or its typical ecosystem.
Then you move on to more complex operations that might involve sequences of operations, like cycling a bit or two to effect some communication with the device. Or it might be as simple as finding the proper sequence of registers to access for operation of a SPI interface. Often, you will find small chunks of code are complete enough to be re-used by your driver; like how to read or write an individual byte. You can then make that a reusable function to simplify the rest of the work, like accessing certain registers in sequence and printing the contents of register that you read to see if they make sense. Ultimately, you will have two important pieces of information: and understanding of the low-level register accesses needed to create a formal driver, and an understanding of what components and capabilities make up the hardware (ie, you know how the device(s) work).
Now, throw away most of what you’ve done, and develop a formal spec. Use what you now know to include everything that can be useful. Use what you now know to develop a spec that includes an appropriate interface API that your application code can use. Rewrite the driver, armed with the knowledge of how are the pieces work, and taking advantage of the blank canvas afforded you by the fresh rewrite of the spec. Only reuse code that you are completely confident is optimal and appropriate to the format dictated by the spec. Write test code for all of the modules, and use the test code to actually test that the code works and that it conforms to the spec. Re-use the test code every time you modify anything it tests.

ESP8266, ESP-01, uploading firmware, module led shine/lights weakly

My problem pertains module ESP8266, specifically version ESP-01.
When I have uploaded firmware (nodemcu) to the module then it works all right.
But later, I found out that the module is not responding. Even after so much restarts.
In addition, the led on the module shines/ligths very weakly.
I don't know where is the problem. Maybe with power supplying but I am using usb-to-serial converter which provides 5V as well as 3V. In addition I am using a voltage regulator from 5V to 3.3V because I wanted to be sure.
Thank you very much.
The problem is that most usb-to-serial interfaces can't provide enough current for the ESP8266 which could draw peak currents of about 320mA. You must use an external power supply.

how to Register for listener in Accelerometer using C

I am working on an STM32f2xx processor eval board, with LIS3lv02dh accelerometer chipset.
I have been able able to program the accelerometer to wakeup the processor on interrupt based on the Threshold level change in accelerometer, but how do I register for events during wakeup.
How do I register an accelerometer sensor handler so that when an interrupt occurs, the application code is notified.
You need to read and understand the STM32f2xx User Reference Manual. You have no OS (I guess) and generic Google searches will not help you; the problem is very specific to the parts you are using.
The STM32F2xxx Standard Peripheral Library (downloadable from ST's site) contains numerous examples for all peripherals including I believe using wake-up sources.
If the accelerometer is included on the evaluation board, I would imagine that it includes example code or a support library that may help.

Resources