Home
JAQForum Ver 24.01
Log In or Join  
Active Topics
Local Time 12:31 13 Jul 2025 Privacy Policy
Jump to

Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me.

Forum Index : Microcontroller and PC projects : SPI affecting COM2 output on Micromite II

Author Message
srnet
Senior Member

Joined: 08/08/2014
Location: United Kingdom
Posts: 164
Posted: 11:14pm 28 Mar 2015
Copy link to clipboard 
Print this post

I have been testing the LoRa receiver, I wanted to send the terminal output via Bluetooth to an Android Tablet (it was free, nice big screen)

The print output routines work well enough when sent to a local VT100 terminal such as TeraTerm.

However, when the same output is sent to COM2, via Bluetooth or direct to a local terminal, the text gets corrupt into a complete mess.

The problem appears to be with SPI, take this routine;

FUNCTION LORA.Checkdevice() AS INTEGER
'check there is a device out there
PRINT #1,"LORA.Checkdevice"
'PAUSE 1000
LOCAL INTEGER LORA_LVAR1, LORA_LVAR2,LORA_LVAR3
'check the 3 frequency setting registers.
PIN(LORA_PNSS) = 0
LORA_LVAR1 = SPI(LORA_RegFrMsb) 'write out the first frequency register to read
LORA_LVAR1 = SPI(0) 'Read RegFrMSB
LORA_LVAR2 = SPI(0) 'Read RegFrMid
LORA_LVAR3 = SPI(0) 'Read RegFrLSB
PIN(LORA_PNSS) = 1
if LORA_LVAR1 <> &H5A OR LORA_LVAR2 <> &HAA OR LORA_LVAR3 <> &HA5 then
LORA.Checkdevice = 0
LORA.FDeviceError = 0
else
LORA.Checkdevice = 1
LORA.FDeviceError = 1
end if
END FUNCTION


If the PAUSE 1000 is there the output is correct "LORA.Checkdevice"

If the SPI commands are removed the output is also correct.

If the pause is out and the SPI commands are there (one is enough) then the output appears as someting like; "LOR-YYice" so there is a mixture of corruption and missing characters.
$50SAT is Silent but probably still working.
For information on LoRa visit http://www.loratracker.uk/

 
Geoffg

Guru

Joined: 06/06/2011
Location: Australia
Posts: 3285
Posted: 03:07am 29 Mar 2015
Copy link to clipboard 
Print this post

This is wrong, SPI does NOT affect COM2:

To make sure I just tested it again and it works fine. I also tested your code and it also worked fine (but because it was incomplete I had to add the OPEN statements).

I am happy to chase down any reports of a bug but you must do some basic tests first to make sure that the "bug" is not a feature of your setup. Also, if you supply some code as a demonstration please don't just copy and paste your program as is - especially if the code is incomplete and will not run. Distil it down to the minimum required to demonstrate the issue and make sure that it will run without the support of your hardware, other routines, etc.

One of the reasons I ask for this is that people will often discover the issue in their own setup as they go through the process of creating a demonstration.

For example, this is the core of your code (it works without error):
Open "COM2:" As #1
SPI open 5000000, 3, 8
Print #1,"LORA.Checkdevice"
var = SPI(123)

Geoff
Geoff Graham - http://geoffg.net
 
srnet
Senior Member

Joined: 08/08/2014
Location: United Kingdom
Posts: 164
Posted: 06:54am 29 Mar 2015
Copy link to clipboard 
Print this post

The problem only seems to occur when the amount of memory used goes above a certain value, you may not see it in a small program.

The attached file produces this output in its current form;

PrU5RJU(iUWCORA.Checkdevice
ERROR, Device not Working

When I either add the PAUSE 1000 or I remove the SPI commands or I remove a batch of the CONST definitions, the Spreading factor and Bandwidth ones (not used by the redacted program) I get;


Program.Setup
LORA.Setup
LORA.Checkdevice
ERROR, Device not Working

2015-03-29_164952_SPI_and_Serial.zip
$50SAT is Silent but probably still working.
For information on LoRa visit http://www.loratracker.uk/

 
Geoffg

Guru

Joined: 06/06/2011
Location: Australia
Posts: 3285
Posted: 05:53pm 29 Mar 2015
Copy link to clipboard 
Print this post

Sorry, but your code worked without error on my test setup.

But, COM2: is bit bashed and relies on interrupts at precise timing intervals and a lot of activity on the SPI port could upset this. This is because of a bug in the MX170 (Errata #10) which requires interrupts to be disabled when sending data on peripherals such as serial, SPI and I2C - maybe your chip is more sensitive to this.

As an experiment I have removed the workaround for the MX170 bug in the attached hex file (Micromite MkII V4.6C Beta 1). The trouble is that this now opens the door to the MX170 bug which may result in intermittent double SPI message being sent - my understanding is that this is unlikely but the potential is there.

Other than this small change this version is identical to V4.6B.
2015-03-30_033815_Micromite-MX170_V4.6CB1.zip

Give it a try and see if it fixes the problem. If it does, but you do not want to run the risk of an occasional double message, you could go back to V4.6B and use COM1 (which is not bit bashed) or run COM2 at a lower baud rate.

Geoff
Geoff Graham - http://geoffg.net
 
srnet
Senior Member

Joined: 08/08/2014
Location: United Kingdom
Posts: 164
Posted: 09:30pm 29 Mar 2015
Copy link to clipboard 
Print this post

Thanks, I will give that a go this evening.

I do have an open log on COM1: so could change the commands across to see if the problem occurs on the hardware interface.

The project needs 4 serial ports, plus the console. GPS, Openlog, serial LCD and (hopefully) a HC-05 Bluetooth adapter, so the soft\bitbang serial is going to be used somewhere.

I would add that the corrupt output, such as PrU5RJU(iUWCORA.Checkdevice, is consistent once the MMII is programmed, the output is exactly the same every time the program runs. The corruption does change slightly if the MMII is reprogrammed to consume different amounts of RAM by adding or removing (unused) constant or variable definitions.

I did spend a long time homing in on the problem, my initial suspicion was the Bluetooth interface, but that works fine when driven directly with no SPI involved and the problem is also seen when a standard USB PC serial port is on COM2:

$50SAT is Silent but probably still working.
For information on LoRa visit http://www.loratracker.uk/

 
srnet
Senior Member

Joined: 08/08/2014
Location: United Kingdom
Posts: 164
Posted: 07:04am 30 Mar 2015
Copy link to clipboard 
Print this post

Before uploading the test firmware I tested the serial output but directed to COM1:, that works OK, no errors in the output.

I then tried the CFunction SerialTX as that can be set up for the same pin as COM2: 30.

When I run this programette;

'Soft Serial TX only

'To do

pin(30) = 1' set the output of the pin high when it is enabled
setpin 30, dout' set the pin as an output

r = SerialTx( 2, 9600, "Hello World" )

END


CFunction SerialTx 00000070
00001021 40824800 40024800 0044102b 1440fffd 00000000 03e00008 00000000
3c03bf81 8c65f000 3c02003d 24420900 7ca51400 70a23002 8c63f000 3c040393
34848700 7c6316c0 00c41021 00621007 3c03029f 24636300 50430003 3c0202dc
03e00008 00000000 03e00008 24426c00 27bdffc0 afb70034 afb1001c afb00018
00c0b821 afa50010 afbf003c afbe0038 afb60030 afb5002c afb40028 afb30024
afb20020 00808021 0411FFDD 00000000 8fa50010 82e30000 8cb10000 00118840
0051001b 022001f4 1860002e 00008812 24160001 3c14bf88 3c15bf88 24120001
8e020000 02202021 00521004 ae826034 24020008 afa20010 241e0001 0411FFC0
00000000 02f69821 1000000c 8fa20010 00721804 aea36038 02202021 afa20010
0411FFB7 00000000 8fa20010 001ef040 2442ffff 10400009 33de00ff 82630000
03c31824 1460fff2 8e030000 00721804 ae836034 1000fff1 02202021 8e020000
02202021 00521004 aea26038 0411FFA4 00000000 82e20000 02c2102a 1440ffd8
26d60001 8fbf003c 00001021 00001821 8fbe0038 8fb70034 8fb60030 8fb5002c
8fb40028 8fb30024 8fb20020 8fb1001c 8fb00018 03e00008 27bd0040
End CFunction


I get an error;

CPU exception #10
In CFunction at address 0x9D00191C
Processor restarted

Next to try the modified firmware.
$50SAT is Silent but probably still working.
For information on LoRa visit http://www.loratracker.uk/

 
viscomjim
Guru

Joined: 08/01/2014
Location: United States
Posts: 925
Posted: 07:36am 30 Mar 2015
Copy link to clipboard 
Print this post

Hi Srnet,

On the CFunction the first line should read...

CFunction SerialTx 0000001C

not

CFunction SerialTx 00000070

If you change that, it should work fine. I am using it now.

Jim

 
srnet
Senior Member

Joined: 08/08/2014
Location: United Kingdom
Posts: 164
Posted: 08:04am 30 Mar 2015
Copy link to clipboard 
Print this post

  viscomjim said   Hi Srnet,
On the CFunction the first line should read...
CFunction SerialTx 0000001C
not
CFunction SerialTx 00000070
If you change that, it should work fine. I am using it now.
Jim


That does it.

I downloaded the original code (with the 00000070) from the 4.6 Library.
$50SAT is Silent but probably still working.
For information on LoRa visit http://www.loratracker.uk/

 
srnet
Senior Member

Joined: 08/08/2014
Location: United Kingdom
Posts: 164
Posted: 09:35am 30 Mar 2015
Copy link to clipboard 
Print this post

  Geoffg said  As an experiment I have removed the workaround for the MX170 bug in the attached hex file (Micromite MkII V4.6C Beta 1). The trouble is that this now opens the door to the MX170 bug which may result in intermittent double SPI message being sent - my understanding is that this is unlikely but the potential is there.


That does appear to fix it, I will check again tommorow with the full setup across to a remote terminal via Bluetooth.

Thanks a lot.
$50SAT is Silent but probably still working.
For information on LoRa visit http://www.loratracker.uk/

 
Geoffg

Guru

Joined: 06/06/2011
Location: Australia
Posts: 3285
Posted: 05:00pm 30 Mar 2015
Copy link to clipboard 
Print this post

I have had another go at it and the attached version should work for you and avoid the MX170 Errata #10 bug.

2015-03-31_025913_Micromite-MX170.V4.6CB2.zip
Geoff Graham - http://geoffg.net
 
srnet
Senior Member

Joined: 08/08/2014
Location: United Kingdom
Posts: 164
Posted: 06:10am 31 Mar 2015
Copy link to clipboard 
Print this post

Thanks again.

That appears to work OK.

What I will do is come up with a test that I can leave running for a few days, if I print a stream of the same message to a terminal (and log) it should be easy enough to spot if the serial output changes. I can then leave it run for a day or so recieving data packets that come in from the SPI.

My 170D was Slicon Revision A2.
$50SAT is Silent but probably still working.
For information on LoRa visit http://www.loratracker.uk/

 
srnet
Senior Member

Joined: 08/08/2014
Location: United Kingdom
Posts: 164
Posted: 09:19pm 31 Mar 2015
Copy link to clipboard 
Print this post

Looks like we have a winner.

I went back to the original program and put a COM2 print statement, just before a long SPI burst read, that was unaffected, the errata #10 workaround was for write errors top SPI, so I guess no work around required for SPI reads.

With the original firmware, this was the output with a COM2 print just before a bunch of SPI writes;

Sta!с KX{ 0 `%H5 *`RRRRRRR b%H * R b%H * R b%H * R r%H * * *
Starting Burst Read 0 69* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

With the latest firmware (thanks again Geoff) this is the output;

COM2 Now Open
Start LoRa Config 0 0* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Starting Burst Read 0 68* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

I have left it running, will check the oputput for errors this evening.
$50SAT is Silent but probably still working.
For information on LoRa visit http://www.loratracker.uk/

 
Geoffg

Guru

Joined: 06/06/2011
Location: Australia
Posts: 3285
Posted: 11:35pm 31 Mar 2015
Copy link to clipboard 
Print this post

That was a subtle problem. I will keep the change in future versions.

Geoff
Geoff Graham - http://geoffg.net
 
srnet
Senior Member

Joined: 08/08/2014
Location: United Kingdom
Posts: 164
Posted: 05:34am 01 Apr 2015
Copy link to clipboard 
Print this post

The program went through 17,500 cycles, there was no corrupt output in the log of data coming from COM2:
$50SAT is Silent but probably still working.
For information on LoRa visit http://www.loratracker.uk/

 
srnet
Senior Member

Joined: 08/08/2014
Location: United Kingdom
Posts: 164
Posted: 08:27am 01 Apr 2015
Copy link to clipboard 
Print this post

And here it is working, the MMII LoRa receiver is receiving LoRa packets from the transmitter (test data).

The receiver sends the data to COM2: via a HC-05 Bluetooth adapter to an Android tablet (Hudl) using VT100 terminal emulation control codes.

The Android 'App' is Blueterm, which unfortunatly does not support the full set of VT100 codes such as save and restore cursor, clear screen and set scroll area do not work, but work arounds are possible.





$50SAT is Silent but probably still working.
For information on LoRa visit http://www.loratracker.uk/

 
Geoffg

Guru

Joined: 06/06/2011
Location: Australia
Posts: 3285
Posted: 10:44am 01 Apr 2015
Copy link to clipboard 
Print this post

Good news.

  srnet said   does not support the full set of VT100 codes such as ... clear screen

That is a serious omission.

Geoff
Geoff Graham - http://geoffg.net
 
srnet
Senior Member

Joined: 08/08/2014
Location: United Kingdom
Posts: 164
Posted: 11:35pm 01 Apr 2015
Copy link to clipboard 
Print this post

  Geoffg said   Good news.

  srnet said   does not support the full set of VT100 codes such as ... clear screen

That is a serious omission.

Geoff


And a surprising one really.

Clear to end of line works, so you can do a routine that positions the cursor at the start of ecah line, and clear the screen that way.
$50SAT is Silent but probably still working.
For information on LoRa visit http://www.loratracker.uk/

 
paceman
Guru

Joined: 07/10/2011
Location: Australia
Posts: 1329
Posted: 02:09am 02 Apr 2015
Copy link to clipboard 
Print this post

Had a quick look and the new Blueterm+ V1.1.0 does have a "Clear Screen".
 
srnet
Senior Member

Joined: 08/08/2014
Location: United Kingdom
Posts: 164
Posted: 02:28am 02 Apr 2015
Copy link to clipboard 
Print this post

  paceman said   Had a quick look and the new Blueterm+ V1.1.0 does have a "Clear Screen".


Yes it does, but you need to be able to send the command to clear screen from the MicroMite application.
$50SAT is Silent but probably still working.
For information on LoRa visit http://www.loratracker.uk/

 
paceman
Guru

Joined: 07/10/2011
Location: Australia
Posts: 1329
Posted: 02:36am 02 Apr 2015
Copy link to clipboard 
Print this post

Ahh yes! - I'd better have a longer read next time.
 
Print this page


To reply to this topic, you need to log in.

The Back Shed's forum code is written, and hosted, in Australia.
© JAQ Software 2025