Configuring STM3210C-EVAL with the lwip example

[Giovanni]

If I remember well, OpenOCD requires an option in order to detect the RTOS, is that the case there?

Giovanni

[pommzorz]

This is true, the -rtos auto option, which is activated in my config...

However I am still clueless about the whole MAC/IP issue. I will update with further data if I happen to find some...

[pommzorz]

Finally found the issue...

STM3210C has the TI DP83848C PHY Chip on board... And thus I inited the board with a false PHY MII ID...

Should I send you the stm3210C board config after i clean it to see if you want to include it in the board files?

Perhaps it would be an interesting id to always include the board.h files in the demo folders, what do you think? Because each time I tried to use an example, I had to adapt the board file by trial and error... This is very interesting but also very time consuming...

Thanks!

[pommzorz]

Another clue on why ChibiOS is not recognized by openOCD :

Code: Select all

TAP: stm32f1x.cpu (enabled)
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x01000000 pc: 0x08000eb0 msp: 0x20000400
ChibiOS registry integrity check failed, NULL pointer
Only showing current execution because of a broken ChibiOS thread registry.

Output of my openOCD console showing some kind of issue... I will look into it...

[pommzorz]

the no-threads shown in eclipse problem has been solved : the command file full-path/xxx.elf was not exactly at the beginning of the init sequence of debugging but in 3rd position and thus it did not work...

Still working my way with another system hang in the lwipThread!

[Giovanni]

Try to find where it hangs and that can give you an hint about the problem.

Giovanni

[pommzorz]

So the exact hang is there in the mac driver lld init :

Code: Select all

 while(ETH->DMABMR & ETH_DMABMR_SR)
    ;

It seems that the lld is waiting for some DMA event and just waiting forever... what I do not like is that this comment is just over the hang : /* MAC clocks activation and commanded reset procedure.*/

Did I fail to configure a working PHY clock again?

When i override that loop every other step from the init passes, but I still do not have any ethernet link...

[Giovanni]

This is very strange, that is the MAC software reset procedure, the core is not coming out of the reset.

The good thing is that at that point it already found the PHY, so that part is OK.

Could you try to put some delay after rccEnableETH(FALSE) just before that loop? Try halPolledDelay(50).

About clocks, are you using a mcuconf.h taken from a F107 demo? they are all different.

Giovanni

[pommzorz]

So this MAC reset is called by the lwipThread when it calls macStart, the halInit completes before without any problem. After adding a small delay as you suggested, the software still hangs at the same spot. I thought that was maybe the ETH driver not being properly inited, but adding macObjectInit(&ETHD1); in the main before the creation of the lwip thread dos not change anything so probably this init is done by halInit or maybe by the lwip thread.

[pommzorz]

Do you have any clue about this hang?

Could that be a wrong GPIO setting ( normally the PHY is now OK but maybe one pin is wrong for some reason? )?

As for the clock the mcuconf.h is the one from the default stm3210C project I think so everything looks OK...