Forum - Recent Threads

RE: HAL Libraries - Importing and Using

14rhb — Wed, 06 Mar 2019 14:21:52 GMT

After the success of getting my UART data sent and even changing the STM32F411RE-Nucleo to read and detect characters in that stream I decided to concentrate on getting the SensorTile to output its data onto the UART5 instead of by 'U' character or 'Thanks Kulky64' message. And this is where the thread comes in again - inspecting the new SimpleUART code (that did work) and combining with my existing SensorTile example code.

Just as before after days I still have the stm32l4xx_hal_uart.h code greyed out after HAL_UART_MODULE_ENABLED as if that define is not known.

I then spent the last three days looking at my xxhal_uart.h and c and comparing to the example xxhal_uart.h and c and found they did differ. My files were made by STM32CubeMX but perhaps the example was built using different options or another version of CubeMX? I thought I might be able to smash together my xxhal_uart.h into the datalog version of hal_uart.h using something like Beyond Compare but I am currently now stuck looking at new undefined errors form other header files.

../../../../../../../Drivers/STM32L4xx_HAL_Driver/Inc/stm32l4xx_hal_uart.h:871:85: note: in definition of macro '__HAL_UART_CLEAR_FLAG'
 #define __HAL_UART_CLEAR_FLAG(__HANDLE__, __FLAG__) ((__HANDLE__)->Instance->ICR = (__FLAG__))
                                                                                     ^~~~~~~~
..\Drivers\STM32L4xx_HAL_Driver\stm32l4xx_hal_uart.c: In function 'UART_DMARxOnlyAbortCallback':
..\Drivers\STM32L4xx_HAL_Driver\stm32l4xx_hal_uart.c:3609:50: error: 'UART_CLEAR_NEF' undeclared (first use in this function)
   __HAL_UART_CLEAR_FLAG(huart, UART_CLEAR_OREF | UART_CLEAR_NEF | UART_CLEAR_PEF | UART_CLEAR_FEF);
                                                  ^
../../../../../../../Drivers/STM32L4xx_HAL_Driver/Inc/stm32l4xx_hal_uart.h:871:85: note: in definition of macro '__HAL_UART_CLEAR_FLAG'
 #define __HAL_UART_CLEAR_FLAG(__HANDLE__, __FLAG__) ((__HANDLE__)->Instance->ICR = (__FLAG__))

I'm carrying on trying to join the two examples but I am finding it really complex.

My conclusion is that this approach is not simple or easy but if you don't have access to the CubeMX code that generated the example then there is no other way.

Rod

RE: HAL Libraries - Importing and Using

14rhb — Mon, 04 Mar 2019 16:20:25 GMT

Thank you. I might try this out after the Sixth Sense Challenge has finished, just in case I damage the board - it would be a shame to do that after getting this far !

Rod

HAL Libraries - Importing and Using

14rhb — Sat, 02 Mar 2019 11:33:45 GMT

I'm after some advice on how to do the following, the discussion will likely be useful to others, so I have broken out to this 'fresh area'. Happy to move if there is a more suitable place.

I'm participating in Sixth Sense Design Challenge and anyone following that will likely see a few posts from me stating that I'm struggling to understand the STM32 development cycle more than the actual range of IDEs. My initial discussion is https://www.element14.com/community/community/design-challenges/sixth-sense-design-challenge/blog/2019/02/25/r2b4-6-sens…

I'm currently using True Studio and STM32L476 although the question could easily relate to the other IDE and/or other devices and boards. I can, with some effort and luck, manage to install and download the examples that are provided in the relevant STM32xx_Cube downloads, I can use STM32xxCubeMX to make a skeleton framework but I seem lost when it comes to adding into an existing project.

For example, I am currently trying to activate the UART5 for that challenge. I have managed to track down the HAL_drivers for the UART in the initial download and add those into my existing project. Partly comparing a simple UART example I made to see what is required. All the HAL_UART functions are greyed out because HAL_UART_MODULE_ENABLED is not defined. When I look at the simple example I see these are defined in STM32xx_HAL_conf.h but in my example from the STM32xxCube package there doesn't appear to be such a file.

If I manage to find a solution I will post it here - current thinking is to (1) simply define the above and see what happens (2) copy the whole header file from another project and adjust for my current one

Any simple tips, explanation of the basics or links to concise articles would be really appreciated. I really want to crack my understanding of these ARM based boards - I have several now and really want to make something useful with them.

Rod

RE: HAL Libraries - Importing and Using

kulky64 — Sun, 03 Mar 2019 21:40:44 GMT

If you want you can try another direction, connect anothwer wire from CN3 pin TX to CN10 pin 35 (maybe you already done that). You have to be careful now and ensure that the MCU on the Nucleo board does not drive the TX line too (because you have now SB63 shorted) -> potential of conflict here. Modify the firmware on the SensorTile so that it sends back every character received or one character higher or something. Type some characters in terminal a watch if they come back. If you are not sure, maybe don't do this exercise.

RE: HAL Libraries - Importing and Using

14rhb — Sun, 03 Mar 2019 20:11:28 GMT

Just like before I read what you said and followed it on the schematics to see if it made sense which it does. A bit of trial-and-error with PuTTY and my SensorTile boards would like to say:

Rod

RE: HAL Libraries - Importing and Using

kulky64 — Sun, 03 Mar 2019 19:01:21 GMT

Glad it is working. Now you can utilize virtual serial port on ST-LINK and check if you receive characters sent by SensorTile in terminal program on your PC. Connect some female to female jumper cable from ST morpho connector CN10 pin 37 (also connected to CN9 pin 1) to connector CN3 pin RX (provided you already opened SB13). Set baudrate and other parameters in your terminal program to match what you set in firmware on your SensorTile and watch if you receive something in terminal.

RE: HAL Libraries - Importing and Using

14rhb — Sun, 03 Mar 2019 18:13:13 GMT

I've got 100% UART data now on CN9-pin1, thank you so much kulky64 for all your time taking me through this.

Point-by-point:

I was looking at CN9-pin2 for the very reason you mention, that is was detailed as the UART_TX but now I see what you mean about being careful. There was nothing on the CN9-pin 1 at this time.
The USB was still connected to my PC and the J2 jumper was incorrectly set to USB.
I changed CubeMX back to provide UART5 as asynchronous rather than half-duplex which I changed whilst trying to mend it earlier.
A few attempts at building, stopping the existing debug etc (just me getting used to the process still) and wow - the oscilloscope trace went wild...zooming in I can easily see my bytes due to the '0101' nature of the 'U' character.

Thanks again for all the time you have spent helping me here. What a great way to finish off Sunday

Rod

RE: HAL Libraries - Importing and Using

kulky64 — Sun, 03 Mar 2019 17:28:19 GMT

14rhb wrote:

... I added some code to output a few bytes on UART5 and LP_UART. I'm seeing bytes on my simple oscilloscope directly from pin 6 of the SensorTile and on CN9-pin2 ...

Whoa. Why do you expecting to see anything on pin 6 of the SensorTile and CN9 pin 2? If you trasmit something from UART5 on SensorTile you should see it on pin 7 of the SensorTile and pin 1 of CN9. So the flow of the signal is like this:

STM32L476JG (PC12, ball B3, UART5_TX) -> SensorTile (pin 7, signal TXD-USB_DM) -> solder bridge SB20 -> level converter ST2378ETTR -> CN9 pin 1 (signal now named UART_RX because this is from MCU on Nucleo point of view).

When you are dealing with RXD and TXD nomenclature you should pay attention from standpoint of which device this is taken. Also just to verify: you have not connected any USB cable to USB connector on the Cradle Expansion Board and jumper on J2 header is placed between 1 and 2 (VIN from Nucleo 5V Output). Right?

RE: HAL Libraries - Importing and Using

14rhb — Sun, 03 Mar 2019 15:24:43 GMT

Hi kulky64, Good point, I compiled the code for reference reading but never actually tried building it or debugging on the SensorTile board. I made a new version in CubeMX (which is a really great tool) and activated both the UART5 and LP_UART. I added some code to output a few bytes on UART5 and LP_UART. I'm seeing bytes on my simple oscilloscope directly from pin 6 of the SensorTile and on CN9-pin2 (having made the SB changes you helpfully suggested). However I wasn't convinced it was actually my bytes (I used the 'U' as it is 0x55 and easy to spot). Commenting out those lines and I could still see data on the CN9-pin2 , which is strange. I'm carrying on looking around. Although I also initialise LP_UART and send bytes to that I cannot see anything on the correct pins of the SensorTile (pins 12 and 13 which are F8 and F9 of the STM32L476JG device). Of course, there is every possibility I have damaged those pins with my clumsy eyesight and shorting pins whilst testing! The data on UART5 also appears whilst single stepping in debug mode, which backs my theory up.

Anyway, the investigation continues, and although I am now a long way from the actual Sixth Sense Design Challenge I feel I am really learning a lot. I even almost successfully imported the BSP for the SensorTile into my project which didn't seem to be an option from CubeMX (I say almost because it fell over compiling).

Apart from these issues I've found it enjoyable looking around the CubeMX to see what can get added, selecting the pins, comparing to the datasheets, testing the pins etc. Thanks for all the help and I'll post when I get another breakthrough (the first breakthrough being my simple code actually compiled and downloaded today).

Rod

RE: HAL Libraries - Importing and Using

kulky64 — Sat, 02 Mar 2019 22:51:16 GMT

Hi, is your basic UART example working? As a starting point try something simple, like sending back every received character. Verify with PuTTY or some other terminal program that it works.

RE: HAL Libraries - Importing and Using

14rhb — Sat, 02 Mar 2019 14:57:51 GMT

Good advice, thank you again Avner.

The more I browse around and try stuff the better I'm getting. I have been in the ...hal_conf.h file and enabled the UART (as in photo below) although that definition never seemed to get recognised in the HAL_UART.c and so I changed the #ifdef to #ifndef to get the code to be included....probably a bad approach as there is something obviously not quite right still. I suspect my includes or where the IDE is looking is incorrect although strangely I can trace through from one declaration to the next (so the IDE knows where everything is even if the compiler doesn't).

I'll likely be giving this a break for now as I think my brain is getting confused - a nice fresh start again tomorrow might help along with all these great comments. A screenshot from my IDE looks like this:

I have two projects open - the SensorTile example and my own, very basic, UART5.

Rod

RE: HAL Libraries - Importing and Using

avnrdf — Sat, 02 Mar 2019 14:24:46 GMT

This is what my project looks like:

CubeMX generated the hal_conf.h file, and automatically defined the macros.

Since you're working with an example project, you could try importing the drivers manually.

The hal_conf.h file also contains a bunch of other defines, and does a:

#ifdef HAL_UART_MODULE_ENABLED
 #include "stm32f1xx_hal_uart.h"
#endif /* HAL_UART_MODULE_ENABLED */

Try generating a new CubeMX project, and look at how the whole thing is structured. I think that you should be able to copy over files from the CubeMX project to your example, and with a little fixing, it should work.

RE: HAL Libraries - Importing and Using

14rhb — Sat, 02 Mar 2019 14:00:31 GMT

Hi Avner,

I wanted to click 'helpful' twice to reflect the amount of great detail you've given me - so thank you.

CubeMX will not modify anything within the /*User Code*/ braces.

I wondered how that bit worked following on from koudelad comments, so will remember that as I start to work my own projects from scratch.

I have managed to do a CubeMX project from scratch, albeit just generating some basic code. The problem I have is that I already have the example from the STM32 board's Cube package, it does 99% of what I want, and now I wish to modify it slightly.

Rod

RE: HAL Libraries - Importing and Using

avnrdf — Sat, 02 Mar 2019 13:28:11 GMT

Rod,

I've been using CubeMX + Atollic Studio to program a STM32F103. I'm using the STM32 HAL, and it seems to be working fine for me.

First setup CubeMX by downloading the MCU Package:

Create a new CubeMX project, and enable the peripherals you want (let's go with the GPIO & UART):

Go to the 'Configuration' tab and configure the settings:

This is how my project settings look:

Note that you can select between the 'LL' & 'HAL'. The HAL is easier to work with due to the higher level of abstraction:

Now click on 'Generate' source code. It should automatically create/update the Atollic TrueStudio Project, add the initialization code (so that you don't need to manually configure the baud rate, and set the GPIOs to the alternate function i.e. UART) & import the required drivers.

Launch TrueStudio, and you will see something like this:

If you open up the those functions, you'll see that CubeMX has already implemented the code required to setup the peripheral.

To transmit you can try adding this after the peripheral initialization:

  char mword [] = "Boot!\n";
  HAL_UART_Transmit(&huart1, &mword, sizeof(mword), 300);

To toggle the GPIO, try:

HAL_GPIO_TogglePin(GPIOC,GPIO_PIN_13);
HAL_Delay(1000);

Have a look at the documentation for the HAL & LL drivers if you want a list of all the driver functions, how to use them or what they do. For the STM32F1, I use this:

Regarding the preprocessor macros/symbols,

TrueStudio > Project > Build Settings > C/C++ Build > Settings > Tool Settings > Symbols (under C Compiler)

I wouldn't bother with copying files over manually - CubeMX does all of that for you!

Create a CubeMX project, and add you code between the /*User Code*/ comments. When you want to modify pinmuxing, enable peripherals, or even change peripheral configuration, open CubeMX, make your changes and regenerate the project. CubeMX will not modify anything within the /*User Code*/ braces.

It's probably easier to start with the CubeMx project, and import whatever code you have rather than the other way around.

RE: HAL Libraries - Importing and Using

14rhb — Sat, 02 Mar 2019 13:11:24 GMT

Hi David,

Thank you for your valuable replies:

If you follow their rules, you can even open the project in CubeMX later and add/remove features later, generate the project again, and your own code stays where it was.

That sounds useful when I am more proficient and then need to expand on my existing projects or change something. Sounds logical as well, like the Microchip Code Configurator (MCC) in PIC program IDE.

I would look for the CubeMX project file

I never thought of doing that - if I can find that file to open directly in CubeMX it would be so much 'easier' ....I'll do some searching around.

Rod

RE: HAL Libraries - Importing and Using

koudelad — Sat, 02 Mar 2019 12:22:33 GMT

Hello Rod,

I don't program STM32s profesionally, but here are a few hints I got at some of ST's seminars:

1) If you have no existing code and want to use CubeMX to generate your code, do it at the beginning and save the CubeMX project file. CubeMX generates a code that contains a lot of blocks of comments that suggest where to put your own code and what not to touch. If you follow their rules, you can even open the project in CubeMX later and add/remove features later, generate the project again, and your own code stays where it was.

2) If ST provided some example you wish to modify, I would look for the CubeMX project file, which leads to the previous step.

David

RE: Is This Situation Repairable

jw0752 — Mon, 04 Sep 2017 01:15:37 GMT

Thanks Doug,

It means a lot to me coming from one of the best inventors / builders / engineers that I know.

John

RE: Is This Situation Repairable

dougw — Mon, 04 Sep 2017 00:35:02 GMT

Outstanding!

Great intuition and curiosity, good sleuthing of the root cause, good research on potential solutions, including very healthy interaction with members, critical confidence to try your solution, and perfect success.

It seems simple enough when reading about it, but how many would actually get it working?

Great work.

RE: Is This Situation Repairable

jw0752 — Sat, 02 Sep 2017 17:44:38 GMT

Thanks Fabio for the assurance. I want to understand things from the foundations but often the foundations are trivial, assumed and not properly covered.

John

Is This Situation Repairable

jw0752 — Sat, 19 Aug 2017 03:37:20 GMT

A while back I posted a blog about building a DSO Shell 15001K Oscilloscope Kit.

https://www.element14.com/community/people/jw0752/blog/2017/04/25/building-the-dso-shell-15001k-oscilloscope

I gave one of these kits to an old friend and he called me a few days later to say that the preliminary test of the Main Board which is done before one starts assembly showed it to be failed We tried a number of diagnostics over the phone and finally I had him send the board to me My tests revealed that there was a low resistance short on the 3.3 volt rail I traced the circuit and removed smd components and cut traces to try to isolate the branch of the 3.3 volt circuit and the component that might be causing the problem Ultimately the fault was in the STM32F103C8T6STM32F103C8T6 microprocessor I removed the microprocessor and decided that the unit was going to be just parts While I can technically replace the uP I have no way to reprogram it As I studied the schematic I noticed that there was in addition to the uP an 8 pin 24LC32A EPROM tied to the SOA and SCL pins of the uP Here is a link to the main board schematic

http://www.jyetech.com/Products/LcdScope/Schematic_150main.pdf

My question is whether there is a possibility that the program for the unit is on the EPROM and not on the uP. Would I be able to replace the fried uP with a raw one and expect it to automatically boot up from the EPROM. At this point it is all just a learning experience but I will probably not waste my money on a uP or my time replacing it if it is impossible for the program to be on the EPROM.

Any insights will be appreciated.

John

RE: Is This Situation Repairable

gecoz — Sat, 02 Sep 2017 16:34:19 GMT

Hi John,

Your statement is absolutely right. UART devices can use different voltages for their logic levels, while still implementing the same communication protocol. In your case, the logic levels of the STM32 UART are 0V low, 3.3V high, so your USB to UART converter was OK. But if you were to use it to interface USB with a TTL UART device (like the Arduino UNO UART for instance), you would have needed a logic level converter, as TTL logic works with 0V low and 5V high levels.

Fabio.

RE: Is This Situation Repairable

jw0752 — Sat, 02 Sep 2017 14:42:41 GMT

Hi Jan,

As I was searching the internet for the shortest easier solution last night I remembered that I had a UART that I used a couple years ago to program an Arduino Mini Pro. Here are pictures of it:

As you can see it is just like the one you recommended without the cord. It is based on the Silabs CP2102.

NOTE: I have need of a clarification:

As long as we are talking I have a clarification question on these UARTs. Most of them have a way of choosing 5V or 3.3V. I am assuming that this is strictly for supplying power to the unit that is being programmed and has nothing to do with logic levels that the UART supplies. This one has 3.3V logic levels and it worked well with my 3.3 V STM 32 microprocessor. If however I was trying to use it on a chip that used 5V logic levels I might have a problem and would have to use a 3.3V to 5V logic converter. I have written this as statements but I need reassurance that I have the right idea about what I have said.

Thanks

John

RE: Is This Situation Repairable

Jan Cumps — Sat, 02 Sep 2017 08:31:42 GMT

Which USB to UART did you end up using, John?

RE: Is This Situation Repairable

jw0752 — Sat, 02 Sep 2017 07:10:11 GMT

This is just an update. The STM 32 microprocessor arrived today and I installed it on the board as well as all the parts I had removed to trace the original short. The chip comes with a pre-installed bootloader. I down loaded an updated firmware from JYE and then I started searching the web for how to upgrade firmware. After a bit (about 2 hours ) of searching and down loading I had my USB UART atached to the computer with the proper driver. I had a USB Flash program from STM up and running and thanks to a you-tube video I knew what to do on the Flash Program to get it to work. To my amazement it all worked as it should and I was able to boot the board to a normal screen.

Thank you for all your suggestions and encouragement. This was a lot of fun.

John

RE: Is This Situation Repairable

jc2048 — Sat, 19 Aug 2017 17:30:32 GMT

Here's another one that doesn't cost much - you even get a free, snap-off, PSoC 4 processor board with it!

It's a CY8CKIT-049-42xx but the I/O is all 5V so it would need level conversion and some of the other suggestions are probably better