Re: BlueSaab Amp pcb!

Posted by sbt on Dec 15, 2016; 7:52am
URL: http://bluesaab-forum.90.s1.nabble.com/BlueSaab-Amp-pcb-tp737p870.html

Thanks for the follow-up on this.

Karlis wrote

Hmm, ok. I have never seen this issue happening before. Here are a couple of things I would be interested to see:

*) What's the "%" setting on RN52? This can be accessed via uploading RN52 programming code and issuing "G%" command.

RN52 programming mode
CMD
0084

Karlis wrote

*) On certain hardware revisions, RN52 PWREN pin needs to be pulled high in order to power it on. RN52 programming code keeps this pin high at all times, that's why this particular issue doesn't manifest itself with programming code.

I have version 5.0, which is always detected correctly. It would explain why the issue only happens with SAAB-CDC.

Karlis wrote

*) Hardware revision is being calculated as an average of ten analogReads from HW check pin. This is done in RN52impl.cpp.

*) A test would be to see what the 'hwRevisionCheckValue' value is after the calculations are made. This can be done by simply adding "Serial.println(hwRevisionCheckValue);" right above line #117.

As above, the version is always correctly detected. I believe the issue relates to the timing for the enable, since time.pulse() holds the pin low for 3000ms before pulling it high for 3000ms. By replacing

time.pulse(BT_PWREN_PIN,3000,0);

 with

time.pulseImmediate(BT_PWREN_PIN,3000,1);,

 I can always get the module up, as this pulls the pin high straight away. However, for completeness, the number returned is 168, right inside the range for version 5.0.

Using time.pulse() or pulseImmediate() also explains why the config commented out later couldn't work; the module isn't awake when that code section is reached (it's not enabled until the time.update() calls are reached in loop()). I've a working mod that uses synchronous calls to digitalWrite to fix this.

There are some robustness issues with Tim Otto's code in the RN52driver parseCmdResponse code that manifest themselves with truncated or otherwise invalid responses from the RN52, such as when changing baud or rebooting. If the RN52 stops sending new characters when the parser is waiting for more to complete an expected response, the system effectively ends up in an infinite loop (but it won't trigger the watchdog, since the loop() still executes).

I suspect it's the delay of module power enable and starting the update() loop that reads the serial port overlapping that are causing the problem with startup I reported. I think they are also the cause of issue #15.

Still more to do.

Cheers,
Sam.