Queries on bootstrapping with MC8090

Hi All.

Currently, we have an SOC, with the following major configurations ::

  • MC8090
  • A solid-state hard-disk, with a Ubuntu-OS.
  • Sierra’s USB-to-WWAN driver for interfacing the above two through serial-port (/dev/ttyUSB3).

Now, things work mostly fine with above, but there is a very important limitation we are facing. During the time wwan0 interface is up, modem-manager in Linux is always bound to /dev/ttyUSB3. As a result, we cannot get access to serial-port through our user-application (or even if we do, it is not exclusive, and thus sending/receiving AT commands/responses get jumbled up).

So, we would be grateful if you experts could let us know how to proceed.

Is there a recommended development-environment, where we can have (pseudo-)exclusive access to serial-port for use with AT-commands? Also, in this case, does the application-binary get flashed onto MC8090 itself, or some external persistent storage?

Alternatively, if we were to continue with the current SOC setup, we were thinking that we could perhaps bypass the USB-to-WWAN driver altogether, and use HAYES-command set while communicating natively between the Ubuntu-OS and MC8090 through serial-port?

Which one would you suggest?

I have some more architectural questions regarding both the above options, but it would be great if you guys could help narrow down to one option.

Eagerly looking to hearing back.

Thanks and Regards,

Any pointers, please?

I might be sounding stupid, but this is really my first experience on MC8090.
In fact, the only Sierra-experience I have is with SL808x series, for which we used the following environment ::

Open-AT Framework within Developer Studio,

Developer Studio on Windows,

USB-driver (source.sierrawireless.com/resour … installer/) to flash the application-binary onto SL808x module itself, wherein the application-binary resides alongside the Open-AT libraries and other firmware-libraries.

As per m2mconnectivity.com.au/brand … -framework, MC8090 is not listed wherein we can use Open-AT/Developer-Studio/Windows environment.

That is the reason for my stupid question. I am a software guy (not really a hardware guy), that is why I am asking such idiotic questions, so that I could understand the architecture for development-environment for MC8090, so that we can make better decision to decide upon the final SOC.


You can stop modemmanager, this will allow you to use the COM-Port again.

Hi fs1.

Thanks for the reply.

Killing modem-manager also drops the connection/interface.
We wish to run AT-commands, while having network-connectivity intact.

You probably have to use mmcli then to setup the connection. All it needs (ok, this depends on the device) is the /dev/cdc-wdm0 device, not the actual serial ports. But there could also be an option in Modemmanager not to access the serial ports, but I haven’t checked that.

So start the connection without using ModemManager at all then…

Your requirements are contradicting. ModemManager is a modem managing application. It cannot manage a DirectIP modem without access to the AT command port. You have some other application that needs to use the AT command port. Then you let that application manage the modem, including the DirectIP network connection. It is as simple as that.

Thanks fs1 and dl5162, we now seem to be getting somewhere :slight_smile:

Cool, so through the last two replies from the experts, my understanding is ::

Do not use modem-manager at all anywhere, instead use mmcli everywhere.

mmcli would be used to initialize the modem, AND setup the connection, AND read SMSes, AND run diagnostic AT-commands. Because we are using mmcli, so that is the only application that will ever have access to the serial-port (/dev/ttyUSB3 in our case).

Above two points would work for the modem even if it is in DirectIP mode (or in other words, we DO NOT NEED to switch the modem into QMI mode). Also, assuming that using the modem in DirectIP is issue-free, we still do need the “sierra” and “serial_net” drivers, but these two drivers work behind the hood; I as the user must only be concerned with mmcli for ALL my actions.

Are ALL my above understandings 100% correct? Or there is something which needs modification above?

If ALL of my above understandings are 100% correct, then it should be easy to do the implementations.
So, will be really grateful if someone could guide my architectural understandings.

Once again, thanks to everyone for the help so far.

Thanks and Regards,