2013-01-02 11:49 PM
We have an STM32373C-EVAL board and we've been trying out the firmware demo samples. One thing I've noticed is that if I enable the USE_FULL_ASSERT, most samples will crash. (Well, not crash but get caught in the assert trap.)
Eg. in the ''STM32F3xx_AN4045_V1.0.0'' (STM32F3xx_IAP), the following will crash:...if (STM_EVAL_PBGetState(BUTTON_KEY) == 0x00)...(Only if you push the button though.)and...FLASH_If_Init();...Is this normal? Should I just disable the USE_FULL_ASSERT and forget about it or is there somewhere where I should submit a bug report? #don't-rush-to-claim-a-bug #stm32f37xx-eval2013-01-03 12:55 AM
Hello, I am not sure about what's the problem but :
If you use FULL_ASSERT, you need this code : For me it is present on every example and it works.#ifdef USE_FULL_ASSERT
/**
* @brief Reports the name of the source file and the source line number * where the assert_param error has occurred. * @param file: pointer to the source file name * @param line: assert_param error line source number * @retval None */ void assert_failed(uint8_t* file, uint32_t line) { /* User can add his own implementation to report the file name and line number, ex: printf(''Wrong parameters value: file %s on line %d\r\n'', file, line) *//* Infinite loop */
while (1) { } } #endif Good Luck.We have an STM32373C-EVAL board and we've been trying out the firmware demo samples. One thing I've noticed is that if I enable the USE_FULL_ASSERT, most samples will crash. (Well, not crash but get caught in the assert trap.)
Eg. in the ''STM32F3xx_AN4045_V1.0.0'' (STM32F3xx_IAP), the following will crash: ... if (STM_EVAL_PBGetState(BUTTON_KEY) == 0x00) ... (Only if you push the button though.) and ... FLASH_If_Init(); ... Is this normal? Should I just disable the USE_FULL_ASSERT and forget about it or is there somewhere where I should submit a bug report?2013-01-03 02:14 AM
The ASSERT macro as found in ST's examples has the same purpose as the Clib functio/macro
assert
. It is used to catch states/expressions which are syntactically correct, but not semantically. In the ST example code, this macro is often used to catch incorrect or meaningless parameters. (I know it from the Discovery firmware and example code, not having an EVAL board). If ST's example code fails such assertions, it is buggy. Seems it was released in a hurry, without thorough testing. If the code works correctly without the USE_FULL_ASSERT, the expectation of the developer had been wrong in this case.2013-01-04 01:31 AM
Yes, that was what I thought as well.
Do you know somewhere where I can submit this bug report?2013-01-04 02:11 AM
Do you know somewhere where I can submit this bug report?
Not really. In open-source applications, you often find ''submit bug reports to ...'' in the release notes. I've found nothing like that yet in any ST firmware. Not sure if they are actually interested ... Maybe you can make some rattling noise, to catch the attention of a ST moderator like ST-One 😉
2013-01-04 03:36 AM
''Do you know somewhere where I can submit this bug report?''
First, you would have to clearly demonstrate that it really is a bug
http://www.catb.org/~esr/faqs/smart-questions.html#idp29846432
Are you sure that you are using the code entirely unmodified, and have correctly configured your project? Have you stepped through the code to see exactly why it is ASSERTing?2013-01-04 04:29 AM
That's why I was asking whether this behavior is to be expected.
And yes, I'm sure that the code is entirely unmodified. And I haven't configured the project in any way, besides adding the USE_FULL_ASSERT. It comes preconfigured from ST. (Two mcu builds are available. I've selected the stm32f37x.) Everything seems to work ... but not when adding the USE_FULL_ASSERT.2013-01-21 07:45 AM
Hi Morten,
Did you tried to build your own example based on the StandardPeriphLibrary for F3 board or even the ST examples other than the IAP one? Best Regards, ST MCUTo give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.