DOTA, Hyperterminal and Terminal Emulator

Legacy Open AT
1

hi

Is there a difference in the way Hyperterminal and the Terminal Emulator (started from the Target Monitoring Tool) handle communication with a FasTrack Supreme? I get the following differences between the two which I can’t explain.

I am using FTP to do DOTA. The file gets downloaded without problems, but then things become strange. If I monitor the DOTA-program’s progress with TMT’s Terminal Emulator everything works fine: the FTP channel, bearer etc. are closed, the A&D cell gets finalized, the new application is installed and the unit reboots with the new software (Hello World sample program) correctly installed. A typical run displays the following:

 ...

+dota: File download completed
+dota: FTP file_channel closed
+dota: FTP channel closed
+dota: A&D cell finalized
+dota: Stopping GPRS bearer
+dota: GPRS bearer stopped
+dota: GPRS bearer closed
+dota: Starting installation

+WIND: 13

+WIND:

Hello World from Open-AT

But if I use Hyperterminal the unit reboots just after the FTP file download is completed, that is

+dota: File download completed

is the last message displayed. The messages about the channels being closed, cell finalized, etc, are never displayed. The reboot InitType is ADL_INIT_REBOOT_FROM_EXCEPTION and the downloaded software is not installed. I ran and compared the two responses (Hyperterminal vs Terminal Emulator) multiple times: it never works when using Hyperterminal, always rebooting immediately after the file is downloaded, and always works when using Terminal Emulator. I do not use TRACE commands; all responses are send using adl_atSendResponse(ADL_AT_RSP, “msg”).

OS=6.20, Firmware=7.3

Thanks for the help.
chris

2

can you try to connect with hyperterminal trough MuxConfTool?
(this is included in the pre-M2M studio SDK’s)

3

I am not using M2M studio. I’m compiling using wmmake and use Hypeterminal and TMT for dowloading and monitoring. Does the OpenAT IDE (version 2.20) have a similar tool that I can try instead?

chris

4

so, yes

5

Apology, I misread your original post.

I found the problem, it was a stack overflow. I can’t explain why it only manifested itself under Hyperterminal but not in the Target Monitoring Tool. But it seems to working fine now.

Thanks for the help
chris

6

It is in the nature of stack overflows to produce “unpredictable” results. :confused:

7

well, but the you’d expect to get the same results (overflow) every time, it doesn’t explain why is happens only with hypertrm connected…
(i actually expect the module to reset when a stack overflow occures.)

8

No, not necessarily.

  • There are probably differences in the precise sequences of AT commands when used “manually” and by M2M studio;
  • The timings will be different;
  • There maybe some difference in the XMODEM implementations

All of which may be enough that you (just) don’t get an overflow one way, but (just) do get an overflow the other…

9

Hiya,

Oh yes. Don’t try to debug SPI/I2C bus timing issues using RTE - the timing is way out.

That makes sense though - in RTE mode, a lot of processing is being done on the PC, and there is the time lag of commands being sent via the serial port…

ciao, Dave

10

hmm. where did you read that he was using RTE?

as far as i understood the problem, hypertrm was used just for monitoring the dota progress.
i find it a bit disturbing that it seems to matter wich program you use to monitor your module?

11

Hiya,

Oops, my bad. Got confused with another post I was reading about using RTE. I think it was this bit that made me Assume that they were using RTE:

Sorry all - although my comments about SPI bus and RTE still stand (just not in the context of this thread) :blush:

ciao, Dave