Problem with Freescale Tower Devkit MCF51CN

konek wrote on Monday, February 15, 2010:

Hi there,

I just found this project on the web and downloaded and compiled the example for the Freescale MCF51CN128 tower kit.
It compiles without errors and warnings on CW 6.2.2 and I can download (flash) it to the MCU.
As given in the manual, the LEDs on the board start flashing at different intervals each.

However I can not connect to the webserver. My local network is and I gave a free address (.222) to the MCU as well as the MAC proposed in the Freescale manuals ( 00 CF 52 35 00 07). PC and devkit are hooked up to a switch (I swapped cables and plugs to make sure it’s not a mechanical issue, the PC works on any line) .

What happenes is that the two LEDs that are built into the RJ45 connector on the Tower Serial Module start flashing (both, the green and the yellow one) at an interval of about two seconds. This stops after a while, then repeats. Seems to be something basic I guess, afaik you see this on network cards while the switch is trying to figure the connection speed (10/100BaseT)?

Any help highly appreciated.


konek wrote on Monday, February 15, 2010:

I forgot to mention, when I compile and flash the Freescale demo that uses MQX, it works just fine. So maybe it is merely a matter of different jumper settings for the RTOS code, but I cant seem to find any further information on this.

rtel wrote on Monday, February 15, 2010:

Are you able to step through the code where the network initialisation is performed to see at what stage it gives up?  That might give a clue.


konek wrote on Monday, February 15, 2010:

Unfortunately I can’t step through it, since the OpenBDM that is implemented in the Tower system seems yet a bit buggy. I’ll only get “Illegal Breakpoint” when trying to do single steps/breakpoints (it’s a known issue).
Is there maybe any docs on the suggested jumper settings? (I am using the out-of-the-box settings)


konek wrote on Tuesday, February 16, 2010:

Fiddling around to get any hints, I commented out all the other demo tasks, just left the blinking LEDs and the webserver.
Et voilà, all of a sudden the thing works! :smiley:

Just for anyone else encountering the same problem, if you look into main() (in main.c of course), there is this block that launches the individual tasks. As you can see I only left the LED flasher alive to see if anything is going on at all:

/* Start the standard demo tasks. */
vStartLEDFlashTasks( tskIDLE_PRIORITY );
// vStartGenericQueueTasks( mainGEN_QUEUE_TASK_PRIORITY );
// vStartQueuePeekTasks();
// vStartRecursiveMutexTasks();
// vStartBlockingQueueTasks( mainBLOCK_Q_PRIORITY );

With these changes, the webserver works PLUS the whole thing consumes a mere 26k! WOW!

So, some demo task keeps the thing from working, but since i dont need these anyways, I wont look any deeper into it.


konek wrote on Tuesday, February 16, 2010:

One more observation for anyone interested in going further from here:
I can now use breakpoints, plus, all the LEDs flash in a constant periodic on-off manner. Before that, it was rather like a pattern, like “beeeep - - - beeeep - - - bip” on the slowest.

All in all I guess that this leads to the inevitable assumption that the MCU simply crashes and resets after like 2 seconds within the original code. Might just be a stacksize issue (though I didnt change any of the original code and stack size definitions).


davedoors wrote on Tuesday, February 16, 2010:

Probably the demo is just running out of heap space. The idle task is created when you call vTaskStartScheduler() and if there is not enough heap space for the idle task then vTaskStartScheduler() will just return. You can put a for(;;); loop after the call to catch it returning. The newest FreeRTOS versions have a malloc failed hook to catch that sort of error.

I bet the compiler version has been updated since the demo was created and the new version is using more RAM.