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
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?
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, to which I have no access to, is causing all the troubles?
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, which is not accessible, is causing all the troubles?
After 4 weeks of trying, debuggin, hoping and sweating I was able to get my server running. The problem was in the SLIP_connect() function: This function provided by the TCPnet library sends "CLIENT<CR>" over the UART interface to the SLIP server (in my case the WLAN module). After examining all the serial data it seemed strange to me that all the AT commands were terminated by <CR><LF> except the CLIENT command. I just had to use com_putchar( <LF> ) after the SLIP_connect() function call.
Id like to thank again for all the help I received.
Thanks for your posts here... They will surely help other..
yateesh
The default Null_Modem.c driver is in the library. However you can copy the source code of this driver from .\ARM\RL\TCPnet\Drivers\Null_Modem.c to your project folder and add it to your project. Then modify it according your needs.
When you build the project, this driver will replace the null modem functions from the library. This is a preferred way and much better than hacking the com_putchar() function.