STM32L496RET6 and ADCs question

12 Jul 2019

Hello everyone,

We have designed our own board using STM32L496RET6. However we have ran into one problem with the ADCs and I would like your opinion.

We program our board using JTAG and MBed. On MBed side, we choose the platform 'DISCO-L496G'. To debug it, we use a TTL cable on Serial pins and a terminal on the computer. We have tested general mathematical calculations, the Serial functionality and PWM functionality of our board (I believe Digital out as well, but I am forgetting now) and they all work fine.

However, whenever we try to introduce an ADC reading, we get the following error on the terminal:

Quote:

++ MbedOS Error Info ++ Error Status: 0x80FF0100 Code: 256 Module: 255 Error Message: Fatal Run-time error Location: 0x800639D Error Value: 0x0 For more info, visit: https://armmbed.github.io/mbedos-error/?error=0x80FF0100 - MbedOS Error Info - HAL_SYSCFG_EnableVREFBUF issue

We have checked the error message on the site they link, but it comes up as an unknown error. Checking mbed-os on github and searching for HAL_SYSCFG_EnableVREFBUF, it says that VREF+ is not connected to VDDA by default. That shouldn't be a problem in our case as we have connected all VDDs together (including VBAT, VUSB etc.). Any ideas why this is? Maybe there is a faulty connection between VDDA and VREF+?

In addition, what is even stranger is that on MBed, when we use the platform 'NUCLEO-L496ZG' nothing works, even though the processor still belongs in the STM32L496 family.

What we are starting to think is that, since the DISCO-L496AG is a different package from our STM32L496RET6, maybe the VDDA is connected differently on that board. If that is the case, which platform should we use to upload a program on our processor?

Thank you in advance! Chris

17 Jul 2019

Can you explain it more clearly?

17 Jul 2019

thao pham wrote:

Can you explain it more clearly?

Hello,

Yes, let me explain it again. We have had some updates on this as well.

So we have designed our own board, on which we use processor STM32L496RET6 (LQFP64 package). To program it we use JTAG connector, and we download the bin file from MBed, then we use STM32 ST-LINK Utility to program the processor.

What is new is that on MBed we used to use platform 'DISCO-L496G' (UFBGA169 package). When we programmed our processor as if it was the DISCO-L496G, we couldn't get the ADCs to work. However now, we started using platform 'NUCLEO-L433RC-P' (LQFP64 package) and this allows us to program the ADCs as well.

So we concluded that the package size mattered. However now, it looks like we are not able to access all the pins on our processor because on the boards we are using as the platform, the pins are not defined as such. For example on STM32L496RET6, PC12 and PD2 can be configured as UART5_TX and UART5_RX. However, on the NUCLEO-L433RC-P, PC12 and PD2 are only labelled as SPI3_MOSI and UART3_RTS. And indeed, we are not able to get a Serial connection from those two pins, even though we should be able to according to the datasheet.

Our question is, which platform would be the best one? There is no development board using STM32L496 and LQFP64 package. Do our conclusions make sense that we are not able to program those pins because they are not defined in the platform itself, or is it more likely to be a problem with our board/UART5?

I hope I explained it better now, thank you, Chris

(I apologise that this might be the wrong forum for this question now, initially we thought it might have been a PCB fault due to the VDDA error we got)

You need to log in to post a reply