![]() |
Forum Index : Microcontroller and PC projects : SPI affecting COM2 output on Micromite II
Author | Message | ||||
srnet Senior Member ![]() Joined: 08/08/2014 Location: United KingdomPosts: 164 |
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: AustraliaPosts: 3285 |
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 KingdomPosts: 164 |
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: AustraliaPosts: 3285 |
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 KingdomPosts: 164 |
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 KingdomPosts: 164 |
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 StatesPosts: 925 |
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 KingdomPosts: 164 |
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 KingdomPosts: 164 |
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: AustraliaPosts: 3285 |
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 KingdomPosts: 164 |
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 KingdomPosts: 164 |
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: AustraliaPosts: 3285 |
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 KingdomPosts: 164 |
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 KingdomPosts: 164 |
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: AustraliaPosts: 3285 |
Good news. That is a serious omission. Geoff Geoff Graham - http://geoffg.net |
||||
srnet Senior Member ![]() Joined: 08/08/2014 Location: United KingdomPosts: 164 |
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: AustraliaPosts: 1329 |
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 KingdomPosts: 164 |
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: AustraliaPosts: 1329 |
Ahh yes! - I'd better have a longer read next time. ![]() |
||||
![]() |
![]() |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |