Closed Nathan-Stohs closed 9 years ago
Just to record what I have done so far on this.
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.
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.
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).
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.
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.
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
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.
Yes, issue with ReservePin() is still open.
I did not observe this issue while testing the LR radio. The LR radio send and receive works (Refer #241 for details). Closing ticket.
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).