forked from ARMmbed/mbed-os
-
Notifications
You must be signed in to change notification settings - Fork 19
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
Synchronize changes with Mbed upstream: July 2024 edition #309
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
NOTE: This fix only targets CAN (M453/M487), not CAN-FD (M467). NOTE: NUC472 CAN doesn't support filter.
Major modifications: 1. Handle Rx interrupt based on Message Object interrupt (CAN_IIDR=0x0001~0x0020) instead of CAN_STATUS.RxOK 2. Also handle Tx interrupt following above for consistency Other related modifications: 1. Fix signature type error in CAN_CLR_INT_PENDING_BIT() 2. Add CAN_CLR_INT_PENDING_ONLY_BIT() which doesn't clear NewDat flag so that user can fetch received message in thread context NOTE: This fix only targets CAN (NUC472/M453/M487), not CAN-FD (M467).
…interrupt 1. The same Message Object number cannot use for both Tx and Rx simultaneously. For Tx, Message Object number 31 is reserved instead of 0. For Rx, Message Object numbers 0~30 are used and for filters. 2. NewDat bit (CAN_IsNewDataReceived()) isn't exclusive to Rx. Recognize Rx interrupt by Message Object number other than 31. NOTE: This fix only targets CAN (NUC472/M453/M487), not CAN-FD (M467).
On mask being zero, it means any match, not exact match. NOTE: This fix only targets CAN (M453/M487), not CAN-FD (M467). NOTE: NUC472 CAN doesn't support filter.
Allow custom TCXO control parameter
ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
Fixes ARMmbed#15498 Adds 2 boolean flags to the STM32 `i2c_s` object to indicate whether a transfer is in progress, separate from the existing "transfer pending" flags. `i2c_slave_write`, `i2c_slave_read` and their associated callbacks are modified to use these flags in addition to the pending flags. The original behavior of the pending flags is preserved.
Problem: The build_ram_table() function of TDBStore loops over every entry, calculates the checksum and compares them to the stored checksum in the entry header to ensure integrity. For larger TDBStores (e.g. 8 MiB or more) in external single-SPI flash devices this check can take very long, thus rendering it unusable in some cases. Solution: The suggested solution skips the time consuming CRC of the data. After reading the key and calculating its CRC, it sets next_offset to the beginning of the next entry, thereby skipping the data. While this skips the integrity check, it significantly reduces the initial building of the RAM table. The data CRC can be enabled or disabled with a compiler flag. Contribution is provided on behalf of BIOTRONIK.
…ew variable Problem: If a key with write-once flag is being set in a SecureStore without rollback-protection store (i.e. _rbp_kv == NULL), additional memory will be allocated for the variable _ih->key. The memory will not be deleted, though, as the delete in line 434 only happens if a rollback-protection store exists (i.e. _rbp_kv != NULL) Solution: Only allocate the memory if _rbp_kv != NULL Contribution is provided on behalf of BIOTRONIK.
For some devices sending can be slow (as an example see SIM800, it can be up to 60s), command is being run properly but default timeout is returning an invalid error. See https://www.elecrow.com/wiki/images/2/20/SIM800_Series_AT_Command_Manual_V1.09.pdf
When SMS list is big and baudrate is not fast enough, with default timeout we can suffer from timeout error while getting a sms because method is parsing the full list and this takes long.
…contained in SMS payload text When parsing SMS, it can happen that we receive CRLF in the SMS payload (happened to me when receiving provider texts). As an example, we can receive: """ Hello <CR><LF> World! """ With previous implementation, second consume_to_stop_tag was stopping in <CR><LF> and rest of the code was failing for obvious reasons. With this commit we consume the full payload as bytes.
JohnK1987
approved these changes
Jul 21, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary of changes
This PR pulls in the last ~4 months of changes from Mbed upstream.
Also had to make a couple additional commits at the end to properly pass the license check, the pin validation check, and the CMSIS MCU descr check. I think upstream must have a broken license check somehow?
Impact of changes
(see PRs linked above)
Migration actions required
To my knowledge, none of the PRs introduce breaking changes
Documentation
(see PRs linked above)
Pull request type
Test results