BMA400 middleware and source code #1
Draft
Conversation
This file contains hidden or 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
Collaborator
|
Is it your intention to remove bmx160 support completely and replace with bma400? I'm just thinking of existing hardware that has bmx160 fitted. Just checking the intention of the change -- sorry for interjecting but I don't have any visibility of the background to the change. |
Author
|
Yes, I had a look at the PSB design and electronic schematics and it seems like the Linkit hardware was designed to incorporate the BMA400. I also searched for the availability of BMX160 accelerometers, but it is a discontinued component. The only way I see that the BMX160 could be used is as a breakout board. There are even solder pads for the BMA400 on the Linkit. So, that is the intention of the change. |
Collaborator
|
I understand. My main point was for older revision of the hardware which
you probably have no visibility of - these older hardware would be fitted
with the now discontinued BMX160 and we use the same binary image on all
the platforms. I just raise this point in case someone still wants to
upgrade the software on their older hardware units. I don't know for sure
if this is the case so it might be worth checking if the intention is to
push this to master.
…On Tue, 25 Apr 2023 at 06:40, Quintin Strydom ***@***.***> wrote:
Yes, I had a look at the PSB design and electronic schematics and it seems
like the Linkit hardware was designed to incorporate the BMA400. I also
searched for the availability of BMX160 accelerometers, but it is a
discontinued component. The only way I see that the BMX160 could be used is
as a breakout board. There are even solder pads for the BMA400 on the
Linkit. So, that is the intention of the change.
I have soldered the BMA400 onto the board (u7), and with the current code
I don't get any response from the accelerometer, so I am not sure if it is
because of the solder connection, or if I where unable to implement the
code correctly.
Linkit V3_1_Schematics_2022-12-13.PDF
<https://github.com/arribada/CLS-Argos-Linkit-CORE/files/11319005/Linkit.V3_1_Schematics_2022-12-13.PDF>
BMA400 datasheet.pdf
<https://github.com/arribada/CLS-Argos-Linkit-CORE/files/11319006/BMA400.datasheet.pdf>
—
Reply to this email directly, view it on GitHub
<#1 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABTRST4PEEUAV3LQ3ZRVLTTXC5PTLANCNFSM6AAAAAAXJZD7XA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Author
|
No the intention is not really to push it to master. I have had contact with Alasdair regarding this request. |
liamw9534
reviewed
Apr 25, 2023
| InterruptLock lock; | ||
| bool value = m_irq_pending; | ||
| m_irq_pending = false; | ||
| DEBUG_TRACE("BMA400LL::check_and_clear_wakeup: pending=%u", (unsigned int)value); |
Collaborator
There was a problem hiding this comment.
Don't do debug trace output inside an interrupt lock.
Collaborator
|
No problem! I'll take a look and review the code. I may have some BMA400
code from another project that I can compare against as well...what is the
error that you are getting?
…On Tue, 25 Apr 2023 at 10:42, Quintin Strydom ***@***.***> wrote:
No the intention is not really to push it to master. I have had contact
with Alasdair regarding this request.
I am not familiar enough with the firmware to ensure that the code will be
compatible or even worth pushing to master. I am not sure if I should
rather have made a pull request to another branch.
I actually just need help to check if it is implemented correctly. Would
it be possible for you to have a look at the code and help me integrate the
BMA400?
—
Reply to this email directly, view it on GitHub
<#1 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABTRSTY5TDEWURFSKNGXIR3XC6MBLANCNFSM6AAAAAAXJZD7XA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
liamw9534
reviewed
Apr 25, 2023
| #include "error.hpp" | ||
| #include "nrf_irq.hpp" | ||
|
|
||
| //Todo: I cannot see the point of this unless there is more than 1 device connected to it. |
Collaborator
There was a problem hiding this comment.
Yes, seems a bit overkill but harmless I suppose.
liamw9534
reviewed
Apr 25, 2023
Comment on lines
135
to
141
| nrfx_twim_xfer_desc_t xfer = NRFX_TWIM_XFER_DESC_TX(device.m_addr, (uint8_t*)buffer, length + sizeof(reg_addr)); | ||
|
|
||
| err_code = nrfx_twim_xfer(&BSP::I2C_Inits[device.m_bus].twim, &xfer, 0); | ||
| //todo: what does this need? | ||
| // err_code = nrfx_twim_tx(&BSP::I2C_Inits[device.m_bus].twim, device.m_addr, buffer, length + sizeof(reg_addr), false); | ||
| if (err_code != NRFX_SUCCESS) | ||
| return BMA400_E_COM_FAIL; |
Collaborator
There was a problem hiding this comment.
I recommend using the NrfI2C wrapper class. See nrf_i2c.hpp. Not sure why the old driver isn't using it but most i2c stuff is now moved over to the wrapper; example: https://github.com/arribada/CLS-Argos-Linkit-CORE/blob/master/ports/nrf52840/core/hardware/ltr_303/ltr_303.cpp.
It handles the exception throwing directly so you don't need your switch table for error checking. Should save some code.
Having said that, I do note that the existing code uses twim_tx and not twim_xfer although it should make no difference judging by your descriptor.
liamw9534
reviewed
Apr 25, 2023
Comment on lines
151
to
163
| nrfx_twim_xfer_desc_t xfer = NRFX_TWIM_XFER_DESC_TXRX(device.m_addr, ®_addr, sizeof(reg_addr), (uint8_t*)reg_data, length); | ||
|
|
||
| err_code = nrfx_twim_xfer(&BSP::I2C_Inits[device.m_bus].twim, &xfer, 0); | ||
|
|
||
| // err_code = nrfx_twim_tx(&BSP::I2C_Inits[device.m_bus].twim, device.m_addr, ®_addr, sizeof(reg_addr), true); | ||
| // if (err_code != NRFX_SUCCESS) | ||
| // return BMA400_E_COM_FAIL; | ||
|
|
||
| // err_code = nrfx_twim_rx(&BSP::I2C_Inits[device.m_bus].twim, device.m_addr, reg_data, length); | ||
| if (err_code != NRFX_SUCCESS) | ||
| return BMA400_E_COM_FAIL; | ||
|
|
||
| return BMA400_OK; |
Collaborator
There was a problem hiding this comment.
In this case I would use the NrfI2C::write (with no_stop=true) and NrfI2C::read following the example of the other drivers.
Collaborator
|
I had a quick scan through and couldn't see anything obvious. I made a few
recommendations. You can check out other drivers that use NrfI2C wrapper
class as it is a bit easier than using the twim driver directly. The only
other things to check would be:
1. You are using the correct bus instance (i.e., on-board versus external)
based on how your peripheral is wired into the board
2. The peripheral is getting powered, check with a multi-meter that you are
getting 3v3 on the VCC of the peripheral when you expect it; also make sure
you have some settling time in case the comms is starting too quickly
before power is applied
3. You are using the correctly assigned i2c address for the slave - some
devices have a range of i2c addresses depending on package pins being left
floating or wired to GND
…On Tue, 25 Apr 2023 at 11:19, Liam Wickins ***@***.***> wrote:
No problem! I'll take a look and review the code. I may have some BMA400
code from another project that I can compare against as well...what is the
error that you are getting?
On Tue, 25 Apr 2023 at 10:42, Quintin Strydom ***@***.***>
wrote:
> No the intention is not really to push it to master. I have had contact
> with Alasdair regarding this request.
> I am not familiar enough with the firmware to ensure that the code will
> be compatible or even worth pushing to master. I am not sure if I should
> rather have made a pull request to another branch.
> I actually just need help to check if it is implemented correctly. Would
> it be possible for you to have a look at the code and help me integrate the
> BMA400?
>
> —
> Reply to this email directly, view it on GitHub
> <#1 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/ABTRSTY5TDEWURFSKNGXIR3XC6MBLANCNFSM6AAAAAAXJZD7XA>
> .
> You are receiving this because you commented.Message ID:
> ***@***.***>
>
|
Author
|
With this current code I am able to build the firmware and flash it to the Linkit using pylinkit. I am just unable to read the config files (parmr, dumpd,...). Thank you. I will apply these changes, do some testing and keep you up to date. |
Collaborator
|
Oh, I see.
Did you try attaching a UART cable to the DBG output pin on the board?
Baud rate is 4680800-8-1-N. It might give some clues about what is
failing. I'm assuming that you had these commands working before on the
previous version of code.
…On Tue, 25 Apr 2023 at 12:00, Quintin Strydom ***@***.***> wrote:
With this current code I am able to build the firmware and flash it to the
Linkit using pylinkit. I am just unable to read the config files (parmr,
dumpd,...).
Thank you. I will apply these changes, do some testing and keep you up to
date.
—
Reply to this email directly, view it on GitHub
<#1 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABTRST7JBA5M7P36U4GVCULXC6VENANCNFSM6AAAAAAXJZD7XA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Author
I was able to read the UART DBG pin, and it seemed to fail with a null pointer error in the Will I be able to flash firmware using DFU mode over USB? Or would you recommend I set up my dev environment to do debugging via the Tag-Connect interface? |
Collaborator
|
Yes, you can use USB to re-flash the firmware. You need to short the DBG
pin to GND while resetting the board to put it into DFU mode. You can then
use nrf-utils to reprogram a DFU zip image over the USB.
On Tue, 2 May 2023 at 09:55, Quintin Strydom ***@***.***>
wrote:
… Oh, I see. Did you try attaching a UART cable to the DBG output pin on the
board? Baud rate is 4680800-8-1-N. It might give some clues about what is
failing. I'm assuming that you had these commands working before on the
previous version of code.
… <#m_4607822741754468654_>
On Tue, 25 Apr 2023 at 12:00, Quintin Strydom *@*.*> wrote: With this
current code I am able to build the firmware and flash it to the Linkit
using pylinkit. I am just unable to read the config files (parmr,
dumpd,...). Thank you. I will apply these changes, do some testing and keep
you up to date. — Reply to this email directly, view it on GitHub <#1
(comment)
<#1 (comment)>>,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABTRST7JBA5M7P36U4GVCULXC6VENANCNFSM6AAAAAAXJZD7XA
<https://github.com/notifications/unsubscribe-auth/ABTRST7JBA5M7P36U4GVCULXC6VENANCNFSM6AAAAAAXJZD7XA>
. You are receiving this because you commented.Message ID: @.*>
I was able to read the UART DBG pin, and it seemed to fail with a null
pointer error in the BMA400LL::init() function.
So, I saw that I did not define m_bma400_dev.intf_ptr. I defined it and
changed some of the code to fit your suggestions and I compiled it and
loaded the firmware. Now the code is stuck in the initialise fase and does
not continue to run anything. I am not sure what caused it to do so, but
that means that I cannot get the Linkit into bluetooth mode to flash new
firmware.
Will I be able to flash firmware using DFU mode over USB? Or would you
recommend I set up my dev environment to do debugging via the Tag-Connect
interface?
—
Reply to this email directly, view it on GitHub
<#1 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABTRST2PGJ5QECXBL4COD3TXEDDXTANCNFSM6AAAAAAXJZD7XA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Author
Oh, and just to note: The debug Baud rate is 460800-8-1-N. I noticed that the documentation also has it like you said (460800), but I found it to not work at that speed. |
Collaborator
|
460800-8-N-1 should work fine for the UART debug port. Excuse my typo.
…On Tue, 2 May 2023 at 10:09, Quintin Strydom ***@***.***> wrote:
Oh, I see. Did you try attaching a UART cable to the DBG output pin on the
board? Baud rate is 4680800-8-1-N. It might give some clues about what is
failing. I'm assuming that you had these commands working before on the
previous version of code.
Oh, and just to note: The debug Baud rate is 460800-8-1-N. I noticed that
the documentation also has it like you said (460800), but I found it to not
work at that speed.
—
Reply to this email directly, view it on GitHub
<#1 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABTRSTYUQFZHE2EZ2ALHXEDXEDFOBANCNFSM6AAAAAAXJZD7XA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Author
|
So, I made a new commit which fixed the null pointer that A problem that I am picking up is that when I connect to the device with bluetooth, I am not able to read config files. It gives the following error: Do you know what might cause this? |
Collaborator
|
Hi there,
From the file
https://github.com/arribada/CLS-Argos-Linkit-CORE/blob/master/core/protocol/dte_handler.hpp
I think this error is here:
enum class DTEError {
OK,
INCORRECT_COMMAND,
NO_LENGTH_DELIMITER,
NO_DATA_DELIMITER,
* DATA_LENGTH_MISMATCH,*
INCORRECT_DATA
};
You could run the pylinkit tool with --debug to see the full trace output
over BLE. I'm not sure why this error would happen unless the transmitted
command to the system has the wrong length. Maybe the debug will give some
clues.
Liam.
…On Thu, 4 May 2023 at 11:13, Quintin Strydom ***@***.***> wrote:
So, I made a new commit which fixed the null pointer that intf_ptr
caused. The code has a bunch of DEBUG_TRACE's that could probably be
removed in a later commit, but helped a lot to track which instructions are
sent to the sensor.
A problem that I am picking up is that when I connect to the device with
bluetooth, I am not able to read config files. It gives the following error:
pylinkit --device EE:4D:40:38:C4:61 --parmr config.txt
2023-05-04 09:13:18,777 client INFO Services resolved for BleakClientWinRT (EE:4D:40:38:C4:61)
Traceback (most recent call last):
File "C:\...\Python\Python39\Scripts\pylinkit-script.py", line 33, in <module>
sys.exit(load_entry_point('pylinkit==3.3.6', 'console_scripts', 'pylinkit')())
File "C:\...\Python\Python39\lib\site-packages\pylinkit-3.3.6-py3.9.egg\pylinkit\__main__.py", line 81, in main
File "C:\...\Python\Python39\lib\site-packages\pylinkit-3.3.6-py3.9.egg\pylinkit\__init__.py", line 23, in sync
File "C:\...\Python\Python39\lib\site-packages\pylinkit-3.3.6-py3.9.egg\pylinkit\dte.py", line 50, in parmr
File "C:\...\Python\Python39\lib\site-packages\pylinkit-3.3.6-py3.9.egg\pylinkit\dte.py", line 35, in _decode_response
Exception: PARMR - error 4
Do you know what might cause this?
—
Reply to this email directly, view it on GitHub
<#1 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABTRST7KEQ4NUFL2L7QL57TXEN6LHANCNFSM6AAAAAAXJZD7XA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Author
|
I tried to see why I am getting the error. So running the v3.3.27 firmware that Philippe sent me, it works perfectly. I then did a Terminal when executing The Debug Trace showed this: This is also the same error that I get when compiling my code for this pull request. |
Collaborator
|
Which compiler version are you using?
…On Thu, 4 May 2023 at 15:08, Quintin Strydom ***@***.***> wrote:
I tried to see why I am getting the error. So running the v3.3.27 firmware
that Philippe sent me, it works perfectly.
I then did a git checkout to the tag v3.3.27 and compiled the code,
uploaded it and I got the same error.
Terminal when executing pylinkit --device EE:4D:40:38:C4:61 --debug
--parmr config1.txt:
2023-05-04 15:59:07,650 client DEBUG Connecting to BLE device @ EE:4D:40:38:C4:61
2023-05-04 15:59:08,784 client DEBUG session_status_changed_event_handler: id: <_bleak_winrt_Windows_Devices_Bluetooth.BluetoothDeviceId object at 0x00000122E00E1390>, error: 0, status: 1
2023-05-04 15:59:08,785 client DEBUG Get Services...
2023-05-04 15:59:11,988 client INFO Services resolved for BleakClientWinRT (EE:4D:40:38:C4:61)
2023-05-04 15:59:12,227 dte_nus DEBUG PC -> DTE: b'$PARMR#000;\r'
2023-05-04 15:59:13,126 dte_nus DEBUG PC <- DTE: $N;PARMR#001;4
Traceback (most recent call last):
File "C:\...\Python39\Scripts\pylinkit-script.py", line 33, in <module>
sys.exit(load_entry_point('pylinkit==3.3.6', 'console_scripts', 'pylinkit')())
File "C:\...\Python39\lib\site-packages\pylinkit-3.3.6-py3.9.egg\pylinkit\__main__.py", line 81, in main
File "C:\...\Python39\lib\site-packages\pylinkit-3.3.6-py3.9.egg\pylinkit\__init__.py", line 23, in sync
File "C:\...\Python39\lib\site-packages\pylinkit-3.3.6-py3.9.egg\pylinkit\dte.py", line 50, in parmr
File "C:\...\Python39\lib\site-packages\pylinkit-3.3.6-py3.9.egg\pylinkit\dte.py", line 35, in _decode_response
Exception: PARMR - error 4
2023-05-04 15:59:13,137 client DEBUG Disconnecting from BLE device...
2023-05-04 15:59:16,249 client DEBUG session_status_changed_event_handler: id: <_bleak_winrt_Windows_Devices_Bluetooth.BluetoothDeviceId object at 0x00000122E00E5470>, error: 0, status: 0
The Debug Trace showed this:
<info> app: Start advertising
<info> app: Connected
01/01/1970 00:00:31 [TRACE] IRQ ConfigurationState::on_ble_event: CONNECTED
01/01/1970 00:00:31 [TRACE] IRQ LEDConfigConnected: entry
<info> app: Data len is set to 0x14(537011264)
01/01/1970 00:00:35 [TRACE] IRQ BleInterface::nus_data_handler: received 12 bytes cumulative 12 (00c).
01/01/1970 00:00:35 [TRACE] IRQ ConfigurationState::on_ble_event: DTE_DATA_RECEIVED
01/01/1970 00:00:35 [TRACE] received 12 bytes:
$PARMR#000;
01/01/1970 00:00:35 [ERROR] DTE_PROTOCOL_PAYLOAD_LENGTH_MISMATCH, expected 12 but got 0
01/01/1970 00:00:35 [TRACE] command = 129 expected_args = 1
01/01/1970 00:00:35 [TRACE] error_code 4
01/01/1970 00:00:35 [TRACE] abort error_code 4
01/01/1970 00:00:35 [TRACE] responding: $N;PARMR#001;4
<info> app: Start advertising
<info> app: Disconnected for reason 0x13
01/01/1970 00:00:39 [TRACE] IRQ ConfigurationState::on_ble_event: DISCONNECTED
This is also the same error that I get when compiling my code for this
pull request.
—
Reply to this email directly, view it on GitHub
<#1 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABTRST24DMQFCYOOYWUVIYLXEOZ7DANCNFSM6AAAAAAXJZD7XA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Collaborator
|
I should add that we are building with gcc-arm-none-eabi-9-2019-q4-major.
…On Thu, 4 May 2023 at 16:06, Liam Wickins ***@***.***> wrote:
Which compiler version are you using?
On Thu, 4 May 2023 at 15:08, Quintin Strydom ***@***.***>
wrote:
> I tried to see why I am getting the error. So running the v3.3.27
> firmware that Philippe sent me, it works perfectly.
>
> I then did a git checkout to the tag v3.3.27 and compiled the code,
> uploaded it and I got the same error.
>
> Terminal when executing pylinkit --device EE:4D:40:38:C4:61 --debug
> --parmr config1.txt:
>
> 2023-05-04 15:59:07,650 client DEBUG Connecting to BLE device @ EE:4D:40:38:C4:61
> 2023-05-04 15:59:08,784 client DEBUG session_status_changed_event_handler: id: <_bleak_winrt_Windows_Devices_Bluetooth.BluetoothDeviceId object at 0x00000122E00E1390>, error: 0, status: 1
> 2023-05-04 15:59:08,785 client DEBUG Get Services...
> 2023-05-04 15:59:11,988 client INFO Services resolved for BleakClientWinRT (EE:4D:40:38:C4:61)
> 2023-05-04 15:59:12,227 dte_nus DEBUG PC -> DTE: b'$PARMR#000;\r'
> 2023-05-04 15:59:13,126 dte_nus DEBUG PC <- DTE: $N;PARMR#001;4
> Traceback (most recent call last):
> File "C:\...\Python39\Scripts\pylinkit-script.py", line 33, in <module>
> sys.exit(load_entry_point('pylinkit==3.3.6', 'console_scripts', 'pylinkit')())
> File "C:\...\Python39\lib\site-packages\pylinkit-3.3.6-py3.9.egg\pylinkit\__main__.py", line 81, in main
> File "C:\...\Python39\lib\site-packages\pylinkit-3.3.6-py3.9.egg\pylinkit\__init__.py", line 23, in sync
> File "C:\...\Python39\lib\site-packages\pylinkit-3.3.6-py3.9.egg\pylinkit\dte.py", line 50, in parmr
> File "C:\...\Python39\lib\site-packages\pylinkit-3.3.6-py3.9.egg\pylinkit\dte.py", line 35, in _decode_response
> Exception: PARMR - error 4
> 2023-05-04 15:59:13,137 client DEBUG Disconnecting from BLE device...
> 2023-05-04 15:59:16,249 client DEBUG session_status_changed_event_handler: id: <_bleak_winrt_Windows_Devices_Bluetooth.BluetoothDeviceId object at 0x00000122E00E5470>, error: 0, status: 0
>
> The Debug Trace showed this:
>
> <info> app: Start advertising
> <info> app: Connected
> 01/01/1970 00:00:31 [TRACE] IRQ ConfigurationState::on_ble_event: CONNECTED
> 01/01/1970 00:00:31 [TRACE] IRQ LEDConfigConnected: entry
> <info> app: Data len is set to 0x14(537011264)
> 01/01/1970 00:00:35 [TRACE] IRQ BleInterface::nus_data_handler: received 12 bytes cumulative 12 (00c).
> 01/01/1970 00:00:35 [TRACE] IRQ ConfigurationState::on_ble_event: DTE_DATA_RECEIVED
> 01/01/1970 00:00:35 [TRACE] received 12 bytes:
> $PARMR#000;
> 01/01/1970 00:00:35 [ERROR] DTE_PROTOCOL_PAYLOAD_LENGTH_MISMATCH, expected 12 but got 0
> 01/01/1970 00:00:35 [TRACE] command = 129 expected_args = 1
> 01/01/1970 00:00:35 [TRACE] error_code 4
> 01/01/1970 00:00:35 [TRACE] abort error_code 4
> 01/01/1970 00:00:35 [TRACE] responding: $N;PARMR#001;4
> <info> app: Start advertising
> <info> app: Disconnected for reason 0x13
> 01/01/1970 00:00:39 [TRACE] IRQ ConfigurationState::on_ble_event: DISCONNECTED
>
> This is also the same error that I get when compiling my code for this
> pull request.
>
> —
> Reply to this email directly, view it on GitHub
> <#1 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/ABTRST24DMQFCYOOYWUVIYLXEOZ7DANCNFSM6AAAAAAXJZD7XA>
> .
> You are receiving this because you commented.Message ID:
> ***@***.***>
>
|
Author
This is the compiler I am using: |
Collaborator
|
Ok I'll outline the build steps we are using. Something is different in
your build process that we need to isolate:
1. Compiler version output
arm-none-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/home/liamw/Tools/gcc-arm-none-eabi-9-2019-q4-major/bin/../lib/gcc/arm-none-eabi/9.2.1/lto-wrapper
Target: arm-none-eabi
Configured with:
/mnt/workspace/workspace/GCC-9-pipeline/jenkins-GCC-9-pipeline-100_20191030_1572397542/src/gcc/configure
--target=arm-none-eabi
--prefix=/mnt/workspace/workspace/GCC-9-pipeline/jenkins-GCC-9-pipeline-100_20191030_1572397542/install-native
--libexecdir=/mnt/workspace/workspace/GCC-9-pipeline/jenkins-GCC-9-pipeline-100_20191030_1572397542/install-native/lib
--infodir=/mnt/workspace/workspace/GCC-9-pipeline/jenkins-GCC-9-pipeline-100_20191030_1572397542/install-native/share/doc/gcc-arm-none-eabi/info
--mandir=/mnt/workspace/workspace/GCC-9-pipeline/jenkins-GCC-9-pipeline-100_20191030_1572397542/install-native/share/doc/gcc-arm-none-eabi/man
--htmldir=/mnt/workspace/workspace/GCC-9-pipeline/jenkins-GCC-9-pipeline-100_20191030_1572397542/install-native/share/doc/gcc-arm-none-eabi/html
--pdfdir=/mnt/workspace/workspace/GCC-9-pipeline/jenkins-GCC-9-pipeline-100_20191030_1572397542/install-native/share/doc/gcc-arm-none-eabi/pdf
--enable-languages=c,c++ --enable-plugins --disable-decimal-float
--disable-libffi --disable-libgomp --disable-libmudflap
--disable-libquadmath --disable-libssp --disable-libstdcxx-pch
--disable-nls --disable-shared --disable-threads --disable-tls
--with-gnu-as --with-gnu-ld --with-newlib --with-headers=yes
--with-python-dir=share/gcc-arm-none-eabi
--with-sysroot=/mnt/workspace/workspace/GCC-9-pipeline/jenkins-GCC-9-pipeline-100_20191030_1572397542/install-native/arm-none-eabi
--build=x86_64-linux-gnu --host=x86_64-linux-gnu
--with-gmp=/mnt/workspace/workspace/GCC-9-pipeline/jenkins-GCC-9-pipeline-100_20191030_1572397542/build-native/host-libs/usr
--with-mpfr=/mnt/workspace/workspace/GCC-9-pipeline/jenkins-GCC-9-pipeline-100_20191030_1572397542/build-native/host-libs/usr
--with-mpc=/mnt/workspace/workspace/GCC-9-pipeline/jenkins-GCC-9-pipeline-100_20191030_1572397542/build-native/host-libs/usr
--with-isl=/mnt/workspace/workspace/GCC-9-pipeline/jenkins-GCC-9-pipeline-100_20191030_1572397542/build-native/host-libs/usr
--with-libelf=/mnt/workspace/workspace/GCC-9-pipeline/jenkins-GCC-9-pipeline-100_20191030_1572397542/build-native/host-libs/usr
--with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm'
--with-pkgversion='GNU Tools for Arm Embedded Processors 9-2019-q4-major'
--with-multilib-list=rmprofile
Thread model: single
gcc version 9.2.1 20191025 (release) [ARM/arm-9-branch revision 277599]
(GNU Tools for Arm Embedded Processors 9-2019-q4-major)
Make sure it is on your PATH.
2. Cmake version
cmake --version
cmake version 3.22.1
3. Cmake configuration command
cmake -DCMAKE_TOOLCHAIN_FILE=toolchain_arm_gcc_nrf52.cmake
-DCMAKE_BUILD_TYPE=Release -DDEBUG_LEVEL=4 -DBOARD=LINKIT -DMODEL=CORE .
Make sure any existing build directory or cmake cache files are removed
beforehand.
4. Build
make
5. Programming via DFU
make dfu_app
The above steps should result in a good image.
…On Fri, 5 May 2023 at 12:14, Quintin Strydom ***@***.***> wrote:
Which compiler version are you using?
This is the compiler I am using:
gcc-arm-none-eabi 15:9-2019-q4-0ubuntu1 amd64 GCC cross compiler for ARM
Cortex-R/M processors
—
Reply to this email directly, view it on GitHub
<#1 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABTRST5X2CSXGHZNZ26BABTXETOKXANCNFSM6AAAAAAXJZD7XA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Author
|
The only difference is that I have here is the output of |
Collaborator
|
It shouldn't be required to downgrade cmake. However could be something
different about the build steps you are doing or some other env
difference. Can you confirm your build steps are the same and you are
cleaning out any prior cache?
Also it is worth cross checking the python env you are using. I think you
can do "pip list" to get this information and python --version.
Below is the setup I am using:
1. pip list
Package Version
-------------------- -----------
antlib 1.1b1
anyio 3.6.2
argparse-addons 0.8.0
async-timeout 4.0.2
async-tkinter-loop 0.7.0
asyncio 3.4.3
at-cmd-tool 0.1.0
atomicwrites 1.4.0
attrs 21.2.0
ban-ate 0.1.0
bleak 0.20.0
bleak-winrt 1.2.0
build 0.10.0
CacheControl 0.12.11
certifi 2021.5.30
cffi 1.14.6
charset-normalizer 2.0.2
cleo 2.0.1
click 8.0.3
cls-ate 0.1.0
clx-ate 0.1.0
colorama 0.4.4
contourpy 1.0.6
crashtest 0.4.1
crc8 0.1.0
crcmod 1.7
cryptography 3.4.7
cycler 0.11.0
decorator 5.1.0
distlib 0.3.6
docutils 0.17.1
dulwich 0.21.3
ecdsa 0.18.0
exceptiongroup 1.1.1
falcon 3.0.1
filelock 3.9.1
finder-ble 0.1.0
flet 0.4.2
flet-core 0.4.2
fonttools 4.38.0
future 0.18.2
geocoder 1.38.1
gunicorn 20.1.0
h11 0.14.0
hid 1.0.5
html5lib 1.1
httpcore 0.16.3
httpx 0.23.3
humanfriendly 10.0
idna 3.2
importlib-metadata 5.0.0
importlib-resources 5.10.0
iniconfig 1.1.1
inputimeout 1.0.4
installer 0.6.0
intelhex 2.3.0
jaraco.classes 3.2.3
jsonschema 4.17.3
keyring 23.13.1
Kivy 2.0.0
kivy-deps.angle 0.3.0
kivy-deps.glew 0.3.0
kivy-deps.sdl2 0.3.1
Kivy-examples 2.0.0
Kivy-Garden 0.1.4
kiwisolver 1.4.4
libusb1 1.9.3
lockfile 0.12.2
matplotlib 3.6.2
mocker 1.1.1
more-itertools 9.1.0
msgpack 1.0.5
nrfutil 6.1.7
numpy 1.21.2
oauthlib 3.2.2
packaging 23.0
packet-forwarder 0.22.0
pandas 1.5.0
parse 1.19.0
pc-ble-driver-py 0.17.0
pexpect 4.8.0
piccata 2.0.3
Pillow 8.3.1
pip 21.1.3
pkg-about 1.0.7
pkginfo 1.9.6
platformdirs 2.6.2
pluggy 0.13.1
poetry 1.4.0
poetry-core 1.5.1
poetry-plugin-export 1.3.0
protobuf 3.20.3
psutil 5.9.0
ptyprocess 0.7.0
py 1.10.0
pyasn1 0.4.8
pyasn1-modules 0.2.8
pybantracker 0.6.0
pyboattracker 0.2.0
pycparser 2.20
pyelftools 0.29
Pygments 2.9.0
pykka 3.0.1
pylink-square 0.11.1
pylinkit 3.3.7
pynrfjprog 10.17.3
pyparsing 2.4.7
pypiwin32 223
pyproject-hooks 1.0.0
PyQt5 5.15.7
PyQt5-Qt5 5.15.2
PyQt5-sip 12.11.0
pyqtgraph 0.13.1
pyreadline3 3.4.1
pyrsistent 0.19.3
pyrtlsdr 0.2.93
pysdr 1.2
pysensor-test 0.6.0
pyserial 3.5
pyspinel 1.0.3
pytest 7.2.2
python-dateutil 2.8.2
pytz 2022.4
pyusb 1.2.1
pyvisa 1.11.3
pywin32 301
pywin32-ctypes 0.2.0
PyYAML 6.0
rapidfuzz 2.13.7
ratelim 0.1.6
repath 0.9.0
requests 2.26.0
requests-toolbelt 0.10.1
rfc3986 1.5.0
scipy 1.10.0
service-identity 21.1.0
setuptools 65.4.1
shellingham 1.5.0.post1
six 1.16.0
sniffio 1.3.0
tk 0.1.0
tkreadonly 0.6.1
toga 0.3.0.dev28
toga-core 0.3.0.dev28
toga-winforms 0.3.0.dev28
toml 0.10.2
tomli 2.0.1
tomli-w 1.0.0
tomlkit 0.11.6
tqdm 4.65.0
trove-classifiers 2023.3.9
ttkwidgets 0.12.1
typing-extensions 3.10.0.0
urllib3 1.26.6
virtualenv 20.21.0
watchdog 2.3.1
webencodings 0.5.1
websocket-client 1.5.1
websockets 10.4
wheel 0.37.0
winrt 1.0.21033.1
wrapt 1.15.0
zipp 3.9.0
WARNING: You are using pip version 21.1.3; however, version 23.1.2 is
available.
You should consider upgrading via the
'c:\users\liam\appdata\local\programs\python\python39\python.exe -m pip
install --upgrade pip' command.
I think the critical ones are most likely bleak and bleak-winrt.
2. python --version
Python 3.9.6
Apart form the above, since I've never seen such a problem before, I don't
have any further suggestions at the moment.
Liam.
…On Fri, 5 May 2023 at 13:29, Quintin Strydom ***@***.***> wrote:
The only difference is that I have cmake version 3.26.3
It looks like there are a few dependencies that are going to make it
difficult to downgrade to v3.22.1, but if I need to then I will.
here is the output of arm-none-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-none-eabi/9.2.1/lto-wrapper
Target: arm-none-eabi
Configured with: ../configure --build=x86_64-linux-gnu --prefix=/usr --includedir='/usr/lib/include' --mandir='/usr/lib/share/man' --infodir='/usr/lib/share/info' --sysconfdir=/etc --localstatedir=/var --disable-silent-rules --libdir='/usr/lib/lib/x86_64-linux-gnu' --libexecdir='/usr/lib/lib/x86_64-linux-gnu' --disable-maintainer-mode --disable-dependency-tracking --mandir=/usr/share/man --enable-languages=c,c++,lto --enable-multilib --disable-decimal-float --disable-libffi --disable-libgomp --disable-libmudflap --disable-libquadmath --disable-libssp --disable-libstdcxx-pch --disable-nls --disable-shared --disable-threads --enable-tls --build=x86_64-linux-gnu --target=arm-none-eabi --with-system-zlib --with-gnu-as --with-gnu-ld --with-pkgversion=15:9-2019-q4-0ubuntu1 --without-included-gettext --prefix=/usr/lib --infodir=/usr/share/doc/gcc-arm-none-eabi/info --htmldir=/usr/share/doc/gcc-arm-none-eabi/html --pdfdir=/usr/share/doc/gcc-arm-none-eabi/pdf --bindir=/usr/bin --libexecdir=/usr/lib --libdir=/usr/lib --disable-libstdc++-v3 --host=x86_64-linux-gnu --with-headers=no --without-newlib --with-multilib-list=rmprofile CFLAGS='-g -O2 -fdebug-prefix-map=/build/gcc-arm-none-eabi-Gl9kT9/gcc-arm-none-eabi-9-2019-q4=. -fstack-protector-strong' CPPFLAGS='-Wdate-time -D_FORTIFY_SOURCE=2' CXXFLAGS='-g -O2 -fdebug-prefix-map=/build/gcc-arm-none-eabi-Gl9kT9/gcc-arm-none-eabi-9-2019-q4=. -fstack-protector-strong' FCFLAGS='-g -O2 -fdebug-prefix-map=/build/gcc-arm-none-eabi-Gl9kT9/gcc-arm-none-eabi-9-2019-q4=. -fstack-protector-strong' FFLAGS='-g -O2 -fdebug-prefix-map=/build/gcc-arm-none-eabi-Gl9kT9/gcc-arm-none-eabi-9-2019-q4=. -fstack-protector-strong' GCJFLAGS='-g -O2 -fdebug-prefix-map=/build/gcc-arm-none-eabi-Gl9kT9/gcc-arm-none-eabi-9-2019-q4=. -fstack-protector-strong' LDFLAGS='-Wl,-Bsymbolic-functions -Wl,-z,relro' OBJCFLAGS='-g -O2 -fdebug-prefix-map=/build/gcc-arm-none-eabi-Gl9kT9/gcc-arm-none-eabi-9-2019-q4=. -fstack-protector-strong' OBJCXXFLAGS='-g -O2 -fdebug-prefix-map=/build/gcc-arm-none-eabi-Gl9kT9/gcc-arm-none-eabi-9-2019-q4=. -fstack-protector-strong' INHIBIT_LIBC_CFLAGS=-DUSE_TM_CLONE_REGISTRY=0 AR_FOR_TARGET=arm-none-eabi-ar AS_FOR_TARGET=arm-none-eabi-as LD_FOR_TARGET=arm-none-eabi-ld NM_FOR_TARGET=arm-none-eabi-nm OBJDUMP_FOR_TARGET=arm-none-eabi-objdump RANLIB_FOR_TARGET=arm-none-eabi-ranlib READELF_FOR_TARGET=arm-none-eabi-readelf STRIP_FOR_TARGET=arm-none-eabi-strip
Thread model: single
gcc version 9.2.1 20191025 (release) [ARM/arm-9-branch revision 277599] (15:9-2019-q4-0ubuntu1)
—
Reply to this email directly, view it on GitHub
<#1 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABTRST2XB5FPAXC2LDWB4BLXETXC3ANCNFSM6AAAAAAXJZD7XA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Author
|
I can confirm that I am using the same build steps and I am cleaning out cache. I don't have the same I will try to install that and let you know. Also, I am compiling the code on Ubuntu 20. |
Collaborator
|
I think the ubuntu version shouldn't make a difference. I am using Ubuntu
22.04.1 LTS.
…On Fri, 5 May 2023 at 15:50, Quintin Strydom ***@***.***> wrote:
I can confirm that I am using the same build steps and I am cleaning out
cache.
I don't have the same bleak version, but I did upgrade that.
I don't have winrt or bleak-winrt installed.
I will try to install that and let you know. Also, I am compiling the code
on Ubuntu 20.
—
Reply to this email directly, view it on GitHub
<#1 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABTRSTZEGBI6ZCT5Y2TP6Y3XEUHVBANCNFSM6AAAAAAXJZD7XA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
QuinaGit
commented
May 11, 2023
| int written; | ||
|
|
||
| snprintf(format, sizeof(format), "%%%zu", s.size()); | ||
| snprintf(format, sizeof(format), "%%%u", s.size()); |
Author
There was a problem hiding this comment.
So an update... this is what ended up being the issue with the ble interface.
The %zu and %zX is for a size_t format specifier and gives unexpected results.
Author
There was a problem hiding this comment.
It turned out that these lines caused an error 4 - DTE_PROTOCOL_BAD_FORMAT and an error 5 - DTE_PROTOCOL_PAYLOAD_LENGTH_MISMATCH
Collaborator
|
Hi,
It doesn't make sense that the same compiler version would compile this
code differently. There must be a difference in your arm-gcc install since
snprintf is part of the standard library.
Liam.
…On Thu, 11 May 2023 at 16:32, Quintin Strydom ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In core/protocol/dte_protocol.hpp
<#1 (comment)>
:
> @@ -1066,7 +1066,7 @@ class DTEDecoder {
char format[32];
int written;
- snprintf(format, sizeof(format), "%%%zu", s.size());
+ snprintf(format, sizeof(format), "%%%u", s.size());
It turned out that these lines caused an error 4 - DTE_PROTOCOL_BAD_FORMAT
and an error 5 - DTE_PROTOCOL_PAYLOAD_LENGTH_MISMATCH
—
Reply to this email directly, view it on GitHub
<#1 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABTRST3SEJ3A5S4BZ4E2MMTXFUBATANCNFSM6AAAAAAXJZD7XA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Tooww
added a commit
to Tooww/CLS-Argos-Linkit-CORE
that referenced
this pull request
May 14, 2024
Tooww
added a commit
to Tooww/CLS-Argos-Linkit-CORE
that referenced
this pull request
May 30, 2024
16.1 debug pgysical was good
Tooww
added a commit
to Tooww/CLS-Argos-Linkit-CORE
that referenced
this pull request
Jun 3, 2024
Tooww
added a commit
to Tooww/CLS-Argos-Linkit-CORE
that referenced
this pull request
Jun 7, 2024
Tooww
added a commit
to Tooww/CLS-Argos-Linkit-CORE
that referenced
this pull request
Jun 13, 2024
Tooww
added a commit
to Tooww/CLS-Argos-Linkit-CORE
that referenced
this pull request
Jun 14, 2024
Tooww
added a commit
to Tooww/CLS-Argos-Linkit-CORE
that referenced
this pull request
Jun 18, 2024
NB : for argos msg still unit test pass (compilation test ok)
Tooww
added a commit
to Tooww/CLS-Argos-Linkit-CORE
that referenced
this pull request
Jun 24, 2024
Tooww
added a commit
to Tooww/CLS-Argos-Linkit-CORE
that referenced
this pull request
Jun 24, 2024
Tooww
added a commit
to Tooww/CLS-Argos-Linkit-CORE
that referenced
this pull request
Jul 4, 2024
Tooww
added a commit
to Tooww/CLS-Argos-Linkit-CORE
that referenced
this pull request
Jul 5, 2024
Tooww
added a commit
to Tooww/CLS-Argos-Linkit-CORE
that referenced
this pull request
Jul 9, 2024
Tooww
added a commit
to Tooww/CLS-Argos-Linkit-CORE
that referenced
this pull request
Jul 10, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Hi, this code does not work perfectly.
I intend to write the middleware that enables the bma400 accelerometer to be connected.
There are a few todo's still in the code, because I am unsure of a few things and want to revisit them.
I tried to find all the places in the code where the BMX160 is involved and used that as a reference for the BMA400 integration.
Feel free to edit the code if you find incorrect integration.