ChibiOS Free Embedded RTOS

Giovanni wrote:Note that the HAL in 2.3.1 supports the PLL3 initialization and the generation of the 50MHz through the MCO pin, part of that ad-hoc initialization code probably is no more required.

Ah, yes, I remember seeing that. My project is based on stable version 2.2.3 at the moment, so I still had to init PLL3 manually. If I remember right, I also had to do that init within mac_lld_init rather than in boardInit() (or __early_init()) due to the order in which they're called in relation to the hal_lld_init(). But like you said that's irrelevant in 2.3.1 because hal sets it up for us now.

I'll port and upload the demo based on the latest trunk, however.

I just uploaded a new ethernet demo, which replaces the old demo, that seems to load the ethernet driver ok for the Olimex STM32-P107 board. The new demo is based on the latest trunk and I created a new branch called "stm32_ethernet_wrapper" for it (the old branch is considered obsolete and I'll probably delete it from the svn repo).

I was having trouble getting the sample web server to work in this demo, so I've commented out the starting of that thread for now. Pings seem to work, though. That demo web server uses the netconn api, which I'm not using in my personal project, thus I'm unfamiliar with why it won't start.

The project files are under "demos/ARMCM3-STM32F107-LWIP" and I created a proper branch of trunk this time so it's easier to see exactly what has been modified using svn tools.

The ethernet driver and demo project is still considered very incomplete and has minimal testing, so any improvements are much appreciated

Thx I got your demo up and running.

brian360 wrote:I was having trouble getting the sample web server to work in this demo, so I've commented out the starting of that thread for now. Pings seem to work, though. That demo web server uses the netconn api, which I'm not using in my personal project, thus I'm unfamiliar with why it won't start.

So you are using the "raw" api right? I tried to start using the socket api - but it seems this is also based on netconn. I tried to debug the problem and it seems it is related to tcpip_apimsg in tcpip. If I understand it correctly it uses mb to communicate with the lwip thread. But somehow somewhere it fails to set the apimsg->msg.err to something meaningful. When I activate some lwip debug features, my socket program runs a bit longer but also gets stuck in some similar behavior. I guess I still have some debugging to do...

mabl wrote:So you are using the "raw" api right? I tried to start using the socket api - but it seems this is also based on netconn. I tried to debug the problem and it seems it is related to tcpip_apimsg in tcpip. If I understand it correctly it uses mb to communicate with the lwip thread. But somehow somewhere it fails to set the apimsg->msg.err to something meaningful. When I activate some lwip debug features, my socket program runs a bit longer but also gets stuck in some similar behavior. I guess I still have some debugging to do...

Yes, presently my program is using the raw api only, thus I haven't spent any time debugging the netconn/socket issues.

There could be a problem in the porting layer (lwip/arch). When I originally got the lwip demo up and running, the netconn API seemed to work just fine. That was with lwip-1.3.1. I then later upgraded to lwip-1.4.0.rc1 which required several changes to sys_arch and related files -- it's possible I missed something there with regard to the api messages.

Hey brian360,

thank you for the hint. I think i found the problem (needs further testing though)! sys_arch_sem_wait(sys_sem_t *sem, u32_t timeout) needs to block when timeout=0 is specified:

- u32_t sys_arch_sem_wait(sys_sem_t sem, u32_t timeout)

Blocks the thread while waiting for the semaphore to be
signaled. If the "timeout" argument is non-zero, the thread should
only be blocked for the specified time (measured in
milliseconds). If the "timeout" argument is zero, the thread should be
blocked until the semaphore is signalled.

If the timeout argument is non-zero, the return value is the number of
milliseconds spent waiting for the semaphore to be signaled. If the
semaphore wasn't signaled within the specified time, the return value is
SYS_ARCH_TIMEOUT. If the thread didn't have to wait for the semaphore
(i.e., it was already signaled), the function may return zero.

This also effects the mailboxes.

Mabl, you are correct, this is the reason, recently the macro TIME_INFINITE changed from 0 to 0xffffffff because a request from a user and for consistency with Posix. This is what triggered the problem.

I will merge the new lwIP during 2.3.x and make the necessary changes to the arch file considering the different value of the constant (I suppose the modified file is already in Brian's branch).

Giovanni

Hello,

I just found this interesting discussion about the lwIP on the Olimex STM32-P107 board, using the STE101P.
But I'm not sure if I understood correctly what Brian intended to do. Is this just a port of the official ST lwIP demo (using STM3210C-EVAL with DP83848) for the Olimex board, or what's the idea behind the MAC wrapper?

In general, can different PHYS devices easily replaced, as long as they support RMII/MII, or do for example STE101P and DP83848 need completely different drivers?

Can you please give me a hint where to find Brian's ethernet demo? I couldn't see it in the code example section of the ChibiOS board.

Thanks a lot,
Andy

Hello santatanta,

The idea is to use the common ChibiOS mac driver interface, and each architecture needs its own low level implentation. There is an ST driver for the STM32 MAC, so brian made a wrapper for it, to be a low level driver. Once you have this driver, you can use the mac interface like the other mac drivers in chibios.

Basically it should be straight forward to replace the PHYs. You might need to change some IDs, but it's all minor changes.

You can find the STM32 ethernet branch here:
http://chibios.svn.sourceforge.net/view ... t_wrapper/

Basically you will only need flowing files from the branch:
- mac_lld.c
- stm32_eth.c
- stm32f10x.h

The you can take the lwip code from a chibios demo of you choice. I have the ethernet code working here, and it seems to be quite stable.

Thank you mabl,

thanks for your reply.
I successfully compiled the software (I took the latest source from the chibiOS repository) using CodeSourcery gcc toolchain, and I can see the LEDs blinking on the board. The Link and Data LEDs on the RJ45 jack are also active (I configured the IP suitable for my network). Unfortunately, I cannot access the board via ping or http. There's also no activity on UART3 (I used a scope to monitor the TX pin, because I couldn't find the baudrate configuration - 115200 didn't work)

Are there any manual changes needed to the sourcecode?
My board is a Olimex STM32-P107 Rev A.

If you use the original ST driver, I assume that your demo also uses hardware checksum calculation and DMA transfer for optimized throughput, is this correct?

Have a nice day,
Andy