[Neil MacMullen]

Thanks Jeff.

[Neil MacMullen]

Thanks Mike – much appreciated.

[Neil MacMullen]

Thanks Jeff,
Yes, the router is the DHCP server but I think it highly unlikely it would have served its own address to a client! That leaves the question of how the conduit got that address. The network topology is….

Internet  ---- Router (DHCP server) <--- Wi-Fi link ---> Switch +---- Windows PC
                                                                +----Conduit

I’m almost certain that the switch I’m using does not have DHCP server capability and the Windows PC is also not set up to do this.

Now that the system is working I’m a bit reluctant to deliberately break it again but I may try some more experiments to see if I can reproduce the problem. Unfortunately though I’m unable to sniff the raw Ethernet traffic from the conduit so I only have limited visibility of what’s going on.

[Neil MacMullen]

Jeff,
I set ‘firstTimeSetup’ to true by editing db.json using VI via teraterm. I saved the file and then reopened it to verify that I had made the change correctly. I then issued the ‘reboot’ command via teraterm. After rebooting, I logged back in and examined db.json and observed that ‘firstTimeSetup’ had been set back to false. Remember I had no access to the web UI since I couldn’t get it to assign itself a useful IP address! 😉

>what address did the Conduit assign itself

When I received the conduit from a colleague, it had already been configured to use DHCP and it managed to grab a sensible IP address from the router. It was only later that it got into this state.

My router is 192.168.99.1 and that is also the IP address that the conduit managed to grab (NOT 192.168.2.1). My best theory about how it got into the incorrect state is that it didn’t have visibility of the router when it was rebooted. (The conduit is plugged into a Wi-Fi capable switch which then connected via a rather flaky Wi-Fi link to the router.) At that point it may have remembered that the previous gateway was 192.168.99.1 and claimed this address since no other device appeared to be using it or it might possibly have seen one of the other devices on the switch with a 192.168.99.x address and decided that was an appropriate address range to use.

[Neil MacMullen]

I have had very similar problems. In my case, the issue appears to be that the conduit managed to assign itself the same IP address as my router (I checked this with ‘ifconfig -a’ via the usb debug interface mentioned above). At that point, no amount of fiddling with the dhcp and other ip parameters in db.json was able to get the system back to a sensible state; I tried turning off dhcp and setting a fixed ip address (see http://www.multitech.com/manuals/s000576_1.0.pdf, search for “fixedaddresses”) but this didn’t help.

The only resolution I could find was to set “firstTimeSetup” back to true which seems to have forced some additional configuration on the next reboot. I think Jeff’s advice above may be misleading – my observation is that ‘firsttimesetup’ is a transient flag which is automatically cleared on reboot.

It’s interesting that I couldn’t see any traffic via wireshark (filtered to conduit mac address rather than ip address) when the conduit was in this state despite the fact that ifconfig claimed a few packets had been sent.

[Neil MacMullen]

Ok – I think I have got to the bottom of this.

When you build the libraries, the build.py script appears to collect build products including header files into a directory called ‘build’ which is in the root mbed folder

When the make.py script is run it automatically adds ‘build’ and appropriate subdirectories to the dependency list.

For both of the above steps, ‘build’ is effectively a hardcoded path.

Make.py also accepts a ‘–build’ option to allow you to specify the target directory for application build products. It appears to remove the contents of this directory before starting the build.

The net result is that if you point –build to a directory called ‘build’ you end up deleting the pre-built library files and the overall build fails since relevant header files and libs cannot be found.

The workaround is to ensure that you specify a –build option that points to a uniquely named directoy, e.g. ‘mybuild’.

Can I suggest stating this explicitly in the documentation, or ideally, modifying the scripts to store the library products in a less vulnerable directory – I would have thought that stashing it inside the ‘libraries’ directory would make more sense.

Neil

• This reply was modified 9 years ago by Neil MacMullen.

[Neil MacMullen]

I wasn’t able to find a Win 7 image but did install the SDK on a fresh windows server 2012 image. I was careful to follow the instructions exactly as written and did not install yotta first. Unfortunately I am still seeing exactly the same problem.

[Neil MacMullen]

Thanks Brandon. Good to hear that it has been seen to work at least! I don’t have a Win 7 environment here but I can see if I can spin up a VM over the weekend to try it. If you get a chance to try it on Win 10, I’d also be interested in the result.

Another factor worth mentioning is that I started off by installing yotta on this machine (following the original mbed guidance). I’d hope that the two environments wouldn’t interfere with each other but perhaps I’ve confused python in some way?

[Neil MacMullen]

Brandon,
Thanks for the tip. This addresses the working directory issue but still doesn’t correctly add the appropriate include paths to the command line. For example, mbed.h lives in C:\personal\proj\mbed\libraries\mbed\api\mbed.h but there is no corresponding -I option being generated. Similarly, the required -o library links are missing. Here’s the output from -v… (apologies for any extraneous line-breaks, they’re just an artefact of cutting and pasting from the console)

C:\personal\proj\mbed>python workspace_tools/make.py -m MTS_MDOT_F411RE -t GCC_ARM -c -j 0 –rtos –source=c:\personal\proj\mbed\myapp –build=c:\personal\proj\
mbed\build -v
[WARNING] Using default settings. Define your settings in the file “workspace_tools/private_settings.py” or in “./mbed_settings.py”
Building project MYAPP (MTS_MDOT_F411RE, GCC_ARM)
Compile: main.cpp
[DEBUG] Command: arm-none-eabi-g++ -std=gnu++98 -fno-rtti -c -Wall -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -fmessage-length=0 -fno-excepti
ons -fno-builtin -ffunction-sections -fdata-sections -MMD -fno-delete-null-pointer-checks -fomit-frame-pointer -mcpu=cortex-m4 -mthumb -mfpu=fpv4-sp-d16 -mfloat
-abi=softfp -O2 -DMBED_BUILD_TIMESTAMP=1448025186.8 -DTOOLCHAIN_GCC_ARM -DTOOLCHAIN_GCC -DTARGET_CORTEX_M -D__FPU_PRESENT=1 -DTARGET_MTS_MDOT_F411RE -D__MBED__=
1 -DUSE_PLL_HSE_EXTC=0 -DTARGET_M4 -DTARGET_STM -DHSE_VALUE=26000000 -DVECT_TAB_OFFSET=0x00010000 -DTARGET_STM32F4 -D__CORTEX_M4 -DTARGET_STM32F411RE -DARM_MATH
_CM4 -DOS_CLOCK=96000000 -Ic:\personal\proj\mbed\myapp -Ic:\personal\proj\mbed\myapp\MTS-Utils -Ic:\personal\proj\mbed\myapp -Ic:\personal\proj\mbed\myapp\MTS-U
tils -IC:\personal\proj\mbed\libraries\tests\mbed\env -o c:\personal\proj\mbed\build\.\main.o c:\personal\proj\mbed\myapp\main.cpp
[DEBUG] Return: 1
[DEBUG] Output: c:\personal\proj\mbed\myapp\main.cpp:7:18: fatal error: mbed.h: No such file or directory
[DEBUG] Output: #include “mbed.h”
[DEBUG] Output: ^

Obviously I can manually create a gcc call that will include the appropriate include paths and libraries but isn’t this what make.py is meant to be doing?

Can you confirm that the documentation as written is known to be correct? At the moment I’m not getting a good feeling that make.py is actually the right script to be using!

Thanks,
Neil

• This reply was modified 9 years ago by Neil MacMullen.

[Author]

Posts