I am building an OpenAT application that will require the use of UART1 to be multiplexed. In the final application, I will need route several communication types over the UART1:
AT command access (for diagnostics/test)
RTE access (for trace/debug/programming)
Data-mode interface to OpenAT application for direct control (used for automated test)
I did some digging on the forums and discovered MuxConfTool. I enabled the mux capabilities on my PCs COM1 port (connected to UART1 on my dev kit), and opened two DLCs (COM11 and COM12)
I then configured the Target Management perspective in Developer Studio to use COM11. I can connect successfully, retrieve the target info, and can execute AT commands.
However, when I attempt to launch the application in RTE debug mode, I get the following (cryptic) RTE kernel error message from RemoteTasks Monitor when I start the application:
“SEVERE ERROR: buffer:opic_wrapperQueryForRTE : NULL == opicint_wrapperMapForRTE”
At this point, RTM dies. I can’t debug, and the application is not running.
Anybody have any idea if what I am attempting is possible, and if so, how I do it?
Yes, it is certainly possible - I am doing it as we speak!
Apart from downloading, forget M2M/DeveloperStudio for any kind of target interaction - use the old Target Monitoring Tool (TMT) and Terminal Emulator (TE) instead!
Until a new version of DeveloperStudio is released with working Target Management, that is…
Correct me if I am wrong, but with the old tools (Target Monitor/TerminalEmulator) I am limited to trace debugging, correct? I need breakpoints and stepping.
Assuming that I could get by without real debugging, which kind of build configuration do I need to create the appropriate binary to program the module with my application such that it is compatible with Target Monitor? I am currently using an RTE Debug configuration. I am using an SL6087 module on a WISMO218 dev kit, which from what I understand does not support JTAG, so I don’t exactly have any other options.
I discovered the section of the API that details how to create custom AT command handlers, and for my application this will work perfectly (all the diagnostics commands submitted to the device during test are AT-style anyway).
I’d still like the ability to utilize the multiplexing on UART1 at some point, but for now I can proceed with an all-AT implementation of the test interface.
Please note that RTE mode is indeed not compatible with a connection to the device through MUX protocol.
RTE mode is requiring some things to be enabled deeply at system level, and very too early before the MUX protocol has any chance to be restored after the system reset (since starting the application in RTE mode requires also a device system reset).