In some cases, primarily when surface mounted to a print board the listening mode will fail to supply IPs over DHCP.
On github it was suggested that it may be poor PCB layout, but the board is stable otherwise and the issue can be solved by setting the IP statically when connecting to the softAP.
Is this the code that handles listening mode ?
If so, maybe something is preventing the if sequence from reaching the DHCP line?
wiced_result_t start() {
wiced_result_t result;
if (!(result=wiced_rtos_init_semaphore(&complete)))
if (!(result=setup_soft_ap_credentials()))
if (!(result=wiced_network_up( WICED_AP_INTERFACE, WICED_USE_INTERNAL_DHCP_SERVER, &device_init_ip_settings )))
if (!(result=wiced_dns_redirector_start( &dns_redirector, WICED_AP_INTERFACE )))
result = WICED_SUCCESS;
return result;
}
When the issue happens, I can set the IP to 192.168.0.x, and use the softAP webbased setup to configure wifi settings, and then the device will run fine in regular mode.
Is this a issue that is being worked on, or is it intended/acceptable behavior that a otherwise working setup will fail to establish the DHCP server ?
The issue isn’t presently being worked on since our current knowledge points to an issue with the board the device is mounted to. For example, the device may not be able to draw enough current to be able to bring up the softAP network interface.
Happy to assist you in debugging this issue. First steps are to add some debug info:
Thanks, I will look into recompiling the system firmware.
It just seems odd that it should have enough current to make the AP but not run the DHCP server, it does make an open AP that I can connect to if I use a static ip on my phone, and complete the setup task.
Got the firmware compiling with latest branch, but INFO is not defined, so I am probably missing something.
Used "git clone -b latest https://github.com/spark/firmware.git"to get the firmware.
I ran “make DEBUG_BUILD=y PLATFORM=photon clean all” in firmware/modules dir.
Made the changes to softAP and ran the same command from root of firmware dir.
If I remove the INFO call the firmware seems to compile, but I dont get a system-part1-photon.bin file, or at least I cant find them.
Ah, seems INFO is not in latest branch, I changed the call(s) to LOG and it compiles
The system files comes when running make from inside firmware/modules, so am I surpose to flash the user firmware that is generated when building from the root directory also ?
At the moment I am running a user program loaded from web ide with “SerialDebugOutput debugOutput;” at the top, but “particle serial monitor” does not show any output after flashing the 2 part files I compiled.
Seems the problem is safe mode updater detects that my device is in safe mode after flashing part1, and then overwrites it with the current cloud version. (I am compiling on a different machine than the photon is connected to, so I copy over the part files and flash OTA)
Is it possible to disable safe mode updater for a specific device ?
sofar so good, but the debug messenges stop when going to listening mode.
cp_socket_t*, int) (791):Socket 0 receive bytes 2 of 18
0000006755:DEBUG: int read_packet_and_dispose(tcp_packet_t&, void*, int, wiced_t
cp_socket_t*, int) (791):Socket 0 receive bytes 16 of 16
0000006783:DEBUG: sock_result_t socket_send(sock_handle_t, const void*, socklen_
t) (999):Write 482 bytes to socket 536895080 result=0
0000006797:DEBUG: sock_result_t socket_send(sock_handle_t, const void*, socklen_
t) (999):Write 34 bytes to socket 536895080 result=0
Spark Core or Photon says Hello over USB! 4
Spark Core or Photon says Hello over USB! 5
Spark Core or Photon says Hello over USB! 6
Spark Core or Photon says Hello over USB! 7
Spark Core or Photon says Hello over USB! 8
Spark Core or Photon says Hello over USB! 9
0000013270:DEBUG: int Spark_Disconnect() (634):
0000013275:DEBUG: int Spark_Disconnect() (643):Close Attempt
0000013282:DEBUG: sock_result_t socket_close(sock_handle_t) (936):socket closed
20005e68
0000013291:DEBUG: int Spark_Disconnect() (645):socket_close()=0
0000013297:INFO : void cloud_disconnect(bool) (410):Cloud: disconnected
I loaded the part1 and 2 over dfu this time, and then flashed a simple .ino via “particle flash Bot2 tinker.ino”
SerialDebugOutput debugOutput;
uint32_t counter = 0;
void setup()
{
pinMode(D7,OUTPUT); // Turn on the D7 led so we know it's time
digitalWrite(D7,HIGH); // to open the Serial Terminal.
Serial.begin(9600); // Open serial over USB.
digitalWrite(D7,LOW); // Turn off the D7 led ... your serial is serializing!
}
void loop()
{
Serial.print("Spark Core or Photon says Hello over USB! ");
Serial.println(counter++);
digitalWrite(D7,HIGH);
delay(500);
digitalWrite(D7,LOW);
delay(500);
}
I guess once the photon leaves my app, the serialDebugOutput is no longer in effect ?
Maybe I am not actually compiling the user firmware locally, since I use particle flash to upload it, but its the system firmware I am interested in debugging, so I think thats ok.
Listening mode in softap to be exact.
Must admit im a bit lost in what belongs to what, thers 3 places to run make from as far as I know, main, modules and root.
@MORA, there are only two places really. You compile under “modules” to create the system part images. You compile under “main” to compile user apps. In both cases, if your Photon is connected locally via USB, you can include “program-dfu” in your make line to compile and flash the .bin file over automatically (assuming no errors).
When you compile the system parts and use program-dfu, both part1 and part2 will be flashed and finally tinker will be flashed.
Thanks, so I place a cpp file inside main/src/ and run make … from main dir to make user firmware ?
Originally I compiled on my linux server, but I installed the windows buildchain today and program-dfu make target works, and indeed does install tinker afterwards
But I somehow need to enable the serial debug output for the system files, which seems to be done by including that "serialDebugOutput " as the first line in user firmware.
But softap does not call the user software first afaik ?
To build your own app firmware you’d put it into ./user/applications/<yourApp> and build with make clean all APP=<yourApp> from modules.
I’ve not tried this in connection with program-dfu but I wouldn’t be surprised if it worked just the same.
If you build from main you’ll get a monolitic firmware, containing sys-part1, sys-part2 & app in one bin.
@MORA, actually you make a directory under firmware/user/applications, put ALL your files (application and libraries required). You can compile from main using:
make clean all PLATFORM=photon PARTICLE_DEVELOP=1 APP=appdirectory program-dfu
You can change photon to core, electron or P1. The appdirectory is the directory name you used to put your app and libraries in.
BTW, regardless of what SoftAP does, you still need a setup() and loop() for the code to compile.
On the original topic, is there more information out there on the PCB design issues that might lead to this? We’re having a similar problem with AP/DHCP reliability on our board with a surface mounted Photon that I need to get to the bottom of. Thanks.
I didnt open it, just commented that I had the same problem.
Originally it was suggested that my 16mil traces was on the bottom end of acceptable for the half amp load photon pulls, that may have some truth to it, the voltage drop of 500mA over 16mil is a bit much, although still within the photon vin range.
Also the regulator I am using (TPS54231) is fixed at 570khz, which is close to 2.4ghz at times 4.
However I am not sure the PCB is the real issue here, since the photon is actually able to start the AP, just not the DHCP.
Hence why I am trying to inject some debug in that start call
That’s quite possible - it’s too long since I did a mono-build.