Hi, Im working with an MCBSTM32E (STM32F103ZE chip) evaluation board and Im trying to create a web server on my board. Because theres no Ethernet controller on board Im using an external WiFi module (RS9110-11-21 from Redpine Signals). Ive configured UART2 as my serial connection to the module. In the Net_Config.c file ive unchecked the Ethernet Network Interface and have enabled the SLIP interface. When I try to compile the code I get the following build output message:
Build target 'STM32 Flash' compiling Net_Config.c... linking... .\Obj\Test.axf: Error: L6218E: Undefined symbol dhcp_vcid (referred from at_dhcp.o). .\Obj\Test.axf: Error: L6218E: Undefined symbol own_hw_adr (referred from at_dhcp.o). Target not created
The serial driver file Serial_STM32x.c is included and modified. Has anyone encountered the same problem?
BTW if I enable the Ethernet interface I dont get the error messages but the program will get stuck in the init_TcpNet() function. (Fatal Error Handler)
Thanks, Chris
Im sorry, I forgot to add that I use the SLIP protocol in between the WLAN module and the board.
But you are still using DHCP. Maybe you are calling dhcp_disable() somewhere in your code.
Thanks for your response! I was indeed calling this function. I will have to try it without.
I was able to get my program running. But now Im stuck again with another issue:
I have to establish a SLIP connection with the WLAN module but after calling the slip_listen() function slip_is_up() always returns FALSE. Could it be that I have to use the SLIP_connect() function without a dialnumber? Has anyone made encountered the same problem? Any hints?
slip listen() runs the SLIP in server mode. TCPnet is waiting to accept connections from SLIP clients. Use it if you have a WLAN module that implements a SLIP client.
But most likely you have a SLIP server implemented in WLAN module. Then you have to call slip_connect() to initiate and establish a slip connection with the module.
After I replaced slip_listen() with slip_connect("") the function slip_is_up() returned true. That part should now be working. Do I have to change anything else? According to the PPP example there isnt anything else to configure...What am I missing that Im not able to ping my board?
I did many tests to see if the problems come from the wlan module or from the tcpnet library. Im now quite certain that they arrive on the baord. Is there a way to see if the board has received and decapsulated the SLIP packets? I set a breakpoint inside the tcp task to watch the UART_SR.
Use the debug library and print the SLIP and IP debug messages. They can tell you what is happening. You can use another Serial port or the ITM channel to view the messages.
Thanks for your help! Im not very used to debug such complex programs. I added to my project the TCPD_CM3.lib and the Net_Debug.c. Net_Debug.c enables the error section in Net_lib.c where the messages are printed out by printf. Could you give me a hint how to redirect printf to uart2? (uart1 is used for the connection between host and wlan module)
I used a retarget to forward all my printf calls to the UART2. But those from the Net_lib.c are not visible. Why?
Take a look at TCPnet examples.
If you do not use FlashFS, then redirect the fputc() function. (See the DNS_demo example for MCBSTM32C)
If you use also FlashFS, then you need to modify the sendchar() function. (See the FTP_demo example for MCBSTM32C).
@Franc Urbanc: Just wanted to say that Im very grateful for your help! This debugging library is very useful!
This is the output from the debugger (SLIP full debug/ ICMP full debug):
SLIP:Initialize SLIP interface SLIP:Dialing number: SLIP:Link up, SLIP Connected. SLIP:END char Received, Frame valid. SLIP:END char Received, Frame valid. ICMP:*** Processing ICMP frame *** ICMP: ECHO Request received ICMP: Identifier: 0x0300 ICMP: Sequence: 0x0900 ICMP:Sending ECHO Reply SLIP:Sending SLIP frame... SLIP:Transmitting queued frame.
If I understand this correct then the uC receives the Ping Request and transmits the Ping Reply. I think that the problem is caused by the WLAN module itself because I ruled out the connection between those two by replacing the wires. Another possibility could be that the SLIP send function is not working properly...Any idea how I could rule out the latter one? I already tried to use an intelligent oscilloscope to measure the levels on the Tx/Rx wires and decode the data but it seems like the oscilloscope is corrupting the data. I dont know why it's causing troubles because usually the impedance of the oscilloscopes and the probe should be high enough.
Thanks
This is the output from the debugger (SLIP full debug, ICMP full debug):
It seems like the uC is handling all the data appropriatly... Therefore the problem has to be on the WLAN module. Or could it be that the SLIP send function is causing all the troubles?