UBLOX EVK NINA B1: mbed 5.5 regression on Serial class (nrf5)

[NeilMacMullen]

This code no longer echoes back received characters on 5.5 (commit c9e63f1) although the initial "LOOPBACK SERIAL" message is shown.

`#include "mbed.h"
 
int main()
{
  Serial *pc = new Serial(USBTX, USBRX);
 
  pc->format(8, Serial::None, 1);
  pc->set_flow_control(Serial::RTSCTS);
  pc->baud(115200);
  pc->printf("LOOPBACK SERIAL %d %d>>>>>>\r\n",USBTX,USBRX);
  while (1)
  {
    while (pc->readable())
    {
      char c = pc->getc();
      pc->putc(c);
    }
    Thread::wait(10);
  }
}
`

Description

• Type: Bug

Target
UBLOX_EVK_NINA_B1

Toolchain:
GCC_ARM

[0xc0170]

cc @hasnainvirk @andreaslarssonublox

[0xc0170]

It would help if you can git bisect it. At least to find a revision that worked for you. I assume 5.5.0 worked, 5.5.1 broke it or?

Looking at the git log, I can see this commit - 080c5af that is touching serial in the recent history. Is this one that has affected your code base? I can see it is defined in nina target PinNames, is it correctly set ?

cc @nvlsianpu

[andreaslarssonublox]

Hi, I tested the code above on the latest master i.e. d382d44 and it seems to work. The fix done by @nvlsianpu is actually fixing the issue that is reported. The commit c9e63f1 is earlier in the history before the fix.
@NeilMacMullen can you try with the d382d44 commit instead and see if it works for you?

[NeilMacMullen]

@andreaslarssonublox @0xc0170 commit c9e63f1 is what you get if you run 'mbed new' (at least as of today, 3rd Jul 2017, 1500:Z) so it's not like I've just taken a random build. :-(

Running 'mbed update d382d44 ' inside the mbed-os folder then 'git log -n 1' shows "commit d382d44".

Rebuilding with "mbed compile -c" and reflashing the device, I see exactly the same behaviour unfortunately. (The reason I'm printing out pinnames is because I suspected they might have been accidentally changed but that's not the case for TX and RX. Commenting out the flow-control line makes no difference).

It would help if you can git bisect it.

Unfortunately I don't have time to do this right now but can test a couple of 'major' releases if you can tell me the magic 'mbed update' runes.

[NeilMacMullen]

On further investigation it appears that the problem does NOT appear (with d382d44) on an actual NINA_B1 but does appear with our own design which emulates the pin out. I suspect this is RTS/CTS related so will look at how our schematic might be different. This is definitely new behaviour since OS4.x though - has anything around this area been changed?

Edit

UART pin assignments appear unchanged between working and non-working builds...
TX:6
RX:5
CTS:7
RTS:31

Note, we're using NINA-B112 module. UART_CTS/GPIO_21 is pulled low. UART_RTS/GPIO_20, UART_DSR_PIO_17, UART_DTR/GPIO_16 all NC (floating). Perhaps there has been a change to default configuration of these?

Edit
Using pc->set_flow_control(Serial::Disabled); causes the test application to also fail on the NINA_B1 EVK though I'm not sure this is new behaviour since I recall being surprised that we had to set RTS/CTS flow control to get serial comms. Surely 'Serial::Disabled' should mean "RTS/CTS are ignored" ?

[andreaslarssonublox]

By the way shouldn't the pins for RTS and CTS be passed as well e.g.:
pc->set_flow_control(Serial::RTSCTS,RTS_PIN_NUMBER,CTS_PIN_NUMBER);

See set_flow_control method in SerialBase.h

[NeilMacMullen]

@andreaslarssonublox - yes you are right. These are defaulted to NC which seems.... just a bit counter-intuitive to me (surely they should default to CTS/RTS?). Possibly the reason that bytes are not being received is because the host might be configured to use flow control but since we're pulling CTS low this shouldn't matter. I need to double-check the schematic (can't do this for a few hours) but pretty sure that the CTS pin isn't even connected to our uart header so why would disabling flow control prevent the chip receiving bytes? Perhaps the 'NC' defaults are causing some misconfiguration internally?

[nvlsianpu]

@NeilMacMullen You can disable flow control by default for see: https://developer.mbed.org/teams/Nordic-Semiconductor/wiki/Nordic-platforms-readme#uart-hardware-flow-control-configuration

[NeilMacMullen]

@nvlsianpu I'll give that a try later but the main issue here is that 1) the behaviour has clearly changed and 2) the set_flow_control method should work. At this stage I can't even seem to get it to work reliably on the NINA_BA at commit d382d44 using any combination of settings and specifying the pins in set_flow_control. ( pc->set_flow_control(Serial::Disabled,RTS_PIN_NUMBER,CTS_PIN_NUMBER);) I've also tried telling TeraTerm to use hardware on 'none' FC on the host. What is interesting is that the echoed characters are flushed when the nina is reprogrammed using jflashlite.

[NeilMacMullen]

Ok, I tried the config suggested in the link from @nvlsianpu That doesn't work for me either on NINA_B1 @ commit d382d44 with teraterm set to 'none' and the application 'set_flow_control' line commented out.

Exactly the same source code as above, on exactly the same hardware compiled against mbed @ commit ed4febe works fine