I have measured the voltage on the TX and RX of the USB->serial adapter and it read 3,8V and 3.3V. This was when the adapter was not in use and I suppose these line are high when not in use. Bus as far as you know is this adapter 5V ?
Further the adapter was tested with Terra terminal by shorting RX and TX. It echoes the characters so in principle it is OK. Do you have a tinyClr or .net example to test the USB->serial port? May this can shorten the test.
It became much effort to make a new board working. This board has no use for me when wifi is not available or works unreliable.
the link you sent us shows that device only presenting a 5v wire - usually a sign that it doesn’t operate at a 3v3 logic level, but those voltages that you see present may not line up with that. Fundamentally, the wifi module on the Fez board is operating at 3v3, and the usb-serial needs to work at that level to be able to communicate to this.
I just took another look at the firmware update instructions, and there’s a comment there that might help us.
When the Wi-Fi module starts, it sends a PowerOn message which tells you what firmware version is installed. For example, PowerOn 171117-0328fe3-SPWF04S . In this case the firmware is dated 17 November 2017.
So if you have the board set up with the usb-to-serial connected to the Wifi module, and you have teraterm connected to that serial port, and you then re-power the device (plug in the other USB cable) it should spit out the above power on message and you should be able to see it - swap TX/RX if you can’t, and try powering it up again
I have done what you suggested but teraterm gives no PowerOn message. Even swapped TX/RX (i am pretty sure that these were correct connected) but also no PowerOn message was received. The used USB to Serial cable has 5V 500mA power over the red wire. It also stated that it had 3,3V on RX an TX as used with Arduino’s. The red power wire is not even connected as per GDI instructions. I have even tried the brand new second board (i ordered 2 at Mouser) but it gives the exact same result. Problem is that connecting H1 (BOOT0) to 3,3V doesn’t bring the WiFi module in boot / terminal mode. May be this is because I got boards with an old WiFi hardware). I am not sure what to do next (except for asking a RMA at Mouser).
sorry BOOT0 being connected should put the wifi into bootloader mode, and that message likely comes only when in normal-boot mode. Can you try without connecting it and see if that spews out the status info (or any info?) Cycle BAUD rates along as well, to see if it gets any data out.
If anyone else playing along here at home also has a FEZ wifi board and can test this to prove it does/doesn’t work, that would be great? (And GHI, if you want to send me one for “training” purposes )
Hi, I would give the board one more chance doing it the way I used. Download the little programm I made to set the board in a defined condition.
Deploy and start this program. When you are asked to press the button (output window) → press BTN1. Now your board is in a defined defined condition for updating the Wifi
Module. Repower the board and disconnect it again. Then apply the 4 cables as can be seen on the picture on my repo. Then plug in the 2 USB connectors. Open STMFlashLoaderDemo and select the proper COM port and 115200 baud rate. Press BTN1, then click Next. When it doesn’t connect pull the USB connector of the FEZ board and push it in again. Then click Next again and you should go.
Edit: Forgot one step (second press BTN1), is included now.
I have tried without succes. BTW the project didn’t deploy because it complains about mscorlib was referenced more than once with different versions. I have copied mscorlib.dll from the package folder of my Wifi test to youre packages. Further I commented out the debug text (like System.Diagnostics.Debug.WriteLine(“Hello FEZ”)) because Debug isn’t in Diagnostics on my system. After that the software could deployed!
After fast flashing led1 I have pressed BTN1 and it started slow flashing. After that I have disconnected the USB and connected the serial wires and Boot0 to 3,3V. Connected the two USB and started ST flash demostrator on the serial COM port. ST says that the device isn’t responding.
LED1 was still slow flashing. I think I had to delete the FEZ firmware and put the FEZ into boot mode first?
Perhaps it is helpful if you post a Foto where we can see how you connected the cables. If you follow my instructions exactly it should work. I have the board in front of me and it works every time.
Note that there are 2 longer Thread.Sleep in my code so you have to wait some seconds before pressing BTN1
Yes, I have seen that because I have done the operation with the debugger.
I have pressed next in ST Flash after the function: ResetToUart() was completed.
I will send foto’s. If it works at your site than may be the USB to serial cable connection should be checked again. The adapter iself was tested with TeraTerm by shorting TX and RX.
After having run the Programm a first time with debugger and you then power it up again the Programm will automatically be executed and you see nothing in the debugger. LED1 will go on for 5 sec, then off and after another 2 seconds you can press BTN1 to send the reset signal to the Wifi module. This will then reboot and after this you can click on NEXT and STMFlashLoader will connect.
I have made a foto and checked the wires again. Everything OK.
I have done the operation with the debugger because led1 goes on for 5 sec and than on for 2 seconds and then start fast flashing in WaitForButton. When BTN1 is pushed then the led start slow flashing. Without the debugger (by disconnecting and reconnecting USB) the LED starts direct with slow flashing. And after pressing BTN1 (before Next in flasher) is stays flashing at the same speed. May this is something debugger related?
I think you have connected RX and TX wrong. (zwart = ground, wit = RX (naar USB poort) en groen = TX (van USB poort)). The green cable must be connected to the pin near the ground pin. (see my picture)
This has worked! I have these wires swapped several times in the GHI procedure. But your software has really worked! Your method is much easier and GHI should this make the standaard procedure! Or better they should made it a part of TinyConfig! Not even a need to need. The WiFi module is now updating as I write.
May be in your reset app the other LED should be falshing fast as a sign the button was pressed and the reset is done!
Congratulations !! When I updated the firmware myself it took me many hours as well until I noticed that I had wrongly connected TX and RX (GHI and STM documents not clear enough?).
When you now try the examples from GHI don’t forget to include this code: Actually GHI’s example doesn’t work as is. The following Commands have to be added to prevent the board from working in python mode.
Yes, I have tried the example again and now it generates un unhandled exception in wifi.JoinNetwork and a second time it hangs there forever.
I thought I had to reset WiFi also by connecting GPIO0 t to 3,3V or something. Or was pressng Boot0 button. But first I will add your code because I had something read about the defaulting to Pyton mode (TTL is thid stat or something) . Didn’t remember exactly!
)