Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for SARA-R410 to the Cellular HAL #1532

Merged
merged 20 commits into from May 11, 2018

Conversation

@sergeuz
Copy link
Member

commented Apr 25, 2018

Problem

This PR adds support for U-blox SARA-R410 modules to the Cellular HAL.

The major difference between SARA-U2/G3 and SARA-R4 modules is the network registration process: in case of SARA-R4 the module automatically establishes a PSD (Packed Switched Data) connection as part of the network registration process, so there's no need to activate a PDP context/EPS bearer explicitly. Cellular HAL has been refactored accordingly (and in a backward-compatible way) in order to support different network registration flows.

Additionally, SARA-R4 doesn't currently support the RTS/CTS flow control and this poses a problem for the runtime modem type detection, since we first need to initialize UART without any flow control enabled, detect the modem type and then reinitialize UART if it appears that the modem does support the hardware flow control. Due to that, in my tests the modem (SARA-U270) or the AT command parser sometimes get into a weird unresponsive state (typically after a system reset), which gets resolved only after an automatic modem reset performed by the MDMParser. I can see a similar problem when I run current develop with hardware flow control disabled (i.e. with USE_USART3_HARDWARE_FLOW_CONTROL_RTS_CTS set to 0). I'd like to invite everyone to try to debug this problem. One workaround, as suggested by Andrey, is to store the modem type in a backup register to avoid repeated initialization of the UART after a system reset.

This PR also adds a custom DNS client implementation based on LwIP, which is used specifically for SARA-R4 since the latter doesn't support DNS lookup commands.

Completeness

  • User is totes amazing for contributing!
  • Contributor has signed CLA (Info here)
  • Problem and Solution clearly stated
  • Run unit/integration/application tests on device
  • [N/A] Added documentation
  • Added to CHANGELOG.md after merging (add links to docs and issues)

@sergeuz sergeuz requested review from avtolstoy and technobly Apr 25, 2018

while (_pipeTx.readable())
{
char c = _pipeTx.getc();
USART_SendData(USART3, c);

This comment has been minimized.

Copy link
@avtolstoy

avtolstoy Apr 26, 2018

Member

This will overflow the TX buffer in USART peripheral. I see two possible options here:

txStart();
while (_pipeTx.readable()) {
  os_thread_yield();
}

Or if the idea is not to use interrupts here this loop should instead be transformed into:

USART_ITConfig(USART3, USART_IT_TXE, DISABLE);
while (_pipeTx.readable()) {
  txCopy();
}

This comment has been minimized.

Copy link
@sergeuz

sergeuz Apr 27, 2018

Author Member

I removed this TX flushing logic as discussed

HAL_Pin_Mode(CTS_UC, AF_OUTPUT_PUSHPULL);
} else {
HAL_Pin_Mode(RTS_UC, OUTPUT);
HAL_GPIO_Write(RTS_UC, 0); // VERY IMPORTANT FOR CORRECT OPERATION W/O HW FLOW CONTROL!!

This comment has been minimized.

Copy link
@avtolstoy
@sergeuz

This comment has been minimized.

Copy link
Member Author

commented Apr 27, 2018

c3a2400 reverts part of the UART initialization logic introduced by dff02e7: now the firmware initializes UART with hardware flow control enabled, then performs a runtime modem type detection and, depending on the modem type, reinitializes the UART to disable the flow control. The patch assumes that the modem still keeps the CTS pin in a correct state even if doesn't support the CTS/RTS flow control

@technobly technobly force-pushed the feature/lte branch from e12959c to a172fb9 May 9, 2018

@technobly technobly added this to the 0.8.0-rc.5 milestone May 9, 2018

@technobly technobly force-pushed the feature/lte branch from 9979614 to 39eb428 May 11, 2018

@technobly technobly force-pushed the feature/lte branch from 39eb428 to 50ba4b7 May 11, 2018

was already approved previously

@sergeuz

This comment has been minimized.

Copy link
Member Author

commented May 11, 2018

The latest changes look good, although it took some time to understand all the RSRP/RSRQ range conversions :) Well done 👍

@sergeuz sergeuz merged commit 1b35016 into develop May 11, 2018

2 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
continuous-integration/travis-ci/push The Travis CI build passed
Details

@technobly technobly deleted the feature/lte branch May 11, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.