STM32 eval board version

anonymous wrote on Monday, December 17, 2012:

What versions of stm32 eval board for IAR are currently supported by the freertos demo? I didn’t realize there were substantive differences and acquired an STM3210E-EVAL. I am using The latest IAR version. The demo build without any errors, as does the ST supplied demo. The only difference is that the ST version works and the FR version does not.

Poking down into this, I found the version that I have is fairly different the the point that it is counter productive to try to debug and port it when what I wanted to do was get something up and running fast so I could start to experiment with the FR framework.

I have found B and C versions available but I have seen threads where someone with a C version couldn’t get that to work and HW compatibility was probably the problem. The B version looks most like the version on the FR demo page. There is however, no version listed for it. So maybe the page predates all the subsequent revs. The B version does have the same uC p/n type as what is listed on the demo page. So maybe this rev will run the demo with out incident???

Any help with this would be greatly appreciated.


rtel wrote on Monday, December 17, 2012:

Can you elaborate on “doesn’t work”.  Does the flash program?  Does it reset?  Can you run to main()?  At what point does it go wrong.

The FreeRTOS Cortex-M ports can be used on any Cortex-M board from any manufacturer.  You have to target the build for the right chip in that the memory map and start up files (clock configuration particularly) must be correct.


anonymous wrote on Monday, December 17, 2012:

“Can you elaborate on “doesn’t work”. Does the flash program? Does it reset? Can you run to main()? At what point does it go wrong.”

  - it does reset, it does run to main and I can step it. The lcd display shows nothing other than some faint lines indicating that the display is not working correctly. Examining some .h files, like for lcd, indicates this is potentially very different. I’m not sure beyond that what else may be incompatible.

That said, my goal was to be  able to get something running out of the box so I could evaluate FreeRTOS at the API level. I will be using an STM32F100 not a 103, so debugging the low level aspects of the different 103’s and/or schematics is a waste of time I haven’t budgeted for.

I have replied in advance of looking at you links above, although it is likely I have already been over them to some extent.

he reason for my question about rev’s is that the quickest means to an end is to acquire the one you built the project for, however, I can find no reference to board rev anywhere and when I ordered this one, I thought it was the latest and  I didn’t realize that there were substantial differences.


rtel wrote on Tuesday, December 18, 2012:

The board I have is almost certainly to be a first revision as I tend to get hardware in advance of release.  I don’t think you will be able to purchase anything but the latest revision anyway.  The LCD used on the board is the most likely thing to change as the production life of LCDs is limited as technology advances.  In any case, it might be a completely different LCD if the board is not the same.

The parts of the demo that do not rely on IO should run anyway, provided you have the linker script and start up files correct for your hardware.  As the code is running, then start up would not seem to be an issue.

At what point does it stop running?  If it stops running when you try and start the scheduler then see if the first item in the list on this page helps:

I would suggest starting by ensuring you can blink the LEDs on your hardware.  The LED IO functions can be found in partest.c (historical name, used to stand for “parallel port IO test”).  In main try calling:

vParTestSetLED( 0, 1 ); /* LED 0 on. */
vParTestSetLED( 0, 0 ); /* LED 0 off. */
vParTestSetLED( 1, 1 ); /* LED 1 on. */
vParTestSetLED( 1, 0 ); /* Etc. */
vParTestSetLED( 2, 1 );
vParTestSetLED( 2, 0 );

to see if the LEDs toggle.  If they don’t, adjust the IO used in partest.c (and possibly the prvSetupHardware() function in main.c if that is where the IO port is initialised) until they do.  Once the LEDs work you will get some visual feedback as to whether the code is running.

Next comment out all the demo tasks that are created in main() other than the ones that toggle the LEDs (the LEDs will be toggled either by the Flash tasks, or possibly by software timers) and run the code.  Do the LEDs flash?  If not, what is the code doing and do the flash tasks ever get entered (put a break point at the top of the task).


anonymous wrote on Wednesday, December 19, 2012:

The LED’s are on port F for this board (which the orig didn’t have) and the setup files have a lot of differences, so I had to add all that infrastructure and then it took me a little while to find that a hard coded value in

//#define IS_RCC_APB2_PERIPH(PERIPH) (((PERIPH & 0xFFFFA182) == 0x00) && (PERIPH != 0x00))
#define IS_RCC_APB2_PERIPH(PERIPH) (((PERIPH & 0xFFFFA102) == 0x00) && (PERIPH != 0x00))

need to be changed in order to get the ABP2ENR setup right w/ the assert func hanging.

Now the LED’s blink.

I commented out all the tasks shown below in the snippet

int main( void )
#ifdef DEBUG


/* Create the queue used by the LCD task.  Messages for display on the LCD
are received via this queue. */
xLCDQueue = xQueueCreate( mainLCD_QUEUE_SIZE, sizeof( xLCDMessage ) );

/* Start the standard demo tasks. */
// vStartBlockingQueueTasks( mainBLOCK_Q_PRIORITY );
//        vCreateBlockTimeTasks();
//        vStartSemaphoreTasks( mainSEM_TEST_PRIORITY );
//        vStartPolledQueueTasks( mainQUEUE_POLL_PRIORITY );
//        vStartIntegerMathTasks( mainINTEGER_TASK_PRIORITY );
vStartLEDFlashTasks( mainFLASH_TASK_PRIORITY );
//        vAltStartComTestTasks( mainCOM_TEST_PRIORITY, mainCOM_TEST_BAUD_RATE, mainCOM_TEST_LED );

/* Start the tasks defined within this file/specific to this demo. */
        xTaskCreate( vCheckTask, ( signed portCHAR * ) “Check”, mainCHECK_TASK_STACK_SIZE, NULL ,mainCHECK_TASK_PRIORITY, NULL );
/ xTaskCreate( vLCDTask, ( signed portCHAR * ) “LCD”, configMINIMAL_STACK_SIZE, NULL, tskIDLE_PRIORITY, NULL );

/* The suicide tasks must be created last as they need to know how many
tasks were running prior to their creation in order to ascertain whether
or not the correct/expected number of tasks are running at any given time. */
    vCreateSuicidalTasks( mainCREATOR_TASK_PRIORITY );

   vParTestSetLED( 0, 1 ); /* LED 0 on. */
   vParTestSetLED( 0, 0 ); /* LED 0 off. */
/* Configure the timers used by the fast interrupt timer test. */

/* Start the scheduler. */

/* Will only get here if there was not enough heap space to create the
idle task. */
return 0;

So, I guess I’m probably good for now. The LCD display is more of the same kind of stuff, but probably a lot more.