search

Samraksh / eMote

eMote OS -- Multiple Ports (using .NET MF v4.3)
0 stars 0 forks source link

eMote Long Range Radio test #72

Closed Nathan-Stohs closed 9 years ago

Nathan-Stohs commented 10 years ago

Need better test for long range radio. IIITA is reporting problems and we need a better test to help them debug.

Hardware has been previously verified with bare metal tests and MF driver has been written (basically just the previous radio driver plus a few lines of extra init).

AnanthAtSamraksh commented 10 years ago

Just to record what I have done so far on this.

  1. I tested both the regular and the LR radio (using C# and native tests). Send and receive works on the regular radio. But on the LR radio, only send works.
Nathan-Stohs commented 10 years ago

Please see if you can debug this, I suspect its an MF driver problem. Nived probably just never tested the RX portion.

If you need further assistance or suspect a hardware issue, see me.

AnanthAtSamraksh commented 10 years ago

I tested the LR radio send (using both C# and native tests) and a regular antenna receive (native test) and it works. The regular antenna receive test is here - TestSuite\Radio\Src\Native\Basic\Slave and the LR radio send (native) test is here - TestSuite\RadioLRTest\Src\Native\Level_0B. I got the C# test from India.

Nathan-Stohs commented 10 years ago

Send Renu an email and see if you can further debug what her problem is. Also talk to Chris and see if he wants a permanent test for the long-range radio in the test suite, or whatever he wants (he is our testing maestro).

AnanthAtSamraksh commented 10 years ago

I have made changes and tested that LR radio receive is working (in both C# and native tests). Sent email to Renu to verify that it indeed works.

AnanthAtSamraksh commented 10 years ago

Closing the issue for now. LR send and receive is working for me. Renu yet to test and get back to me. I will reopen the issue if a problem is reported.

AnanthAtSamraksh commented 10 years ago

LR send and receive is working for Renu as well. But for some reason, the function -- CPU_GPIO_ReservePin() -- in netmf_gpio.cpp is being called for pins 32768, 16384 and 8192 (which are not valid pins). Pin 32768 is reserved, but fails when 16384 is called. Because of this, LR radio does not work. I was not able to find out how these pins get called. This is to be investigated later. In the version of the CLR given to Renu, the "Return false" line was commented out to make the LR radio work (which is just a temporary solution).

(Just noting down what I think is the reason behind pins 32768, 16384 and 8192 being called). There are only 15 GPIO pins defined and the function(?) that calls CPU_GPIO_ReservePin() might be using pins not defined (0xFFFF). GPIO pins are defined here -- MF\MicroFrameworkPK_v4_3\DeviceCode\Targets\Native\STM32F10x\DeviceCode\drivers\gpio\stm32f10x_gpio.h

Nathan-Stohs commented 10 years ago

Ananth is the issue with ReservePin() still open? I'm looking to close this. The LR has generally been proven, specific issues can migrate to their own bugs as they come up.

AnanthAtSamraksh commented 10 years ago

Yes, issue with ReservePin() is still open.

AnanthAtSamraksh commented 9 years ago

I did not observe this issue while testing the LR radio. The LR radio send and receive works (Refer #241 for details). Closing ticket.