firmware issueshttps://git.flow3r.garden/card10/firmware/-/issues2019-07-11T10:59:06Zhttps://git.flow3r.garden/card10/firmware/-/issues/32Shitty Addon Module2019-07-11T10:59:06Zrahixcard10@rahix.deShitty Addon ModuleA module to access the shitty addon connector. This requires adding the necessary calls to Epicardium API ([Guide](https://card10.badge.events.ccc.de/en/firmware/epicardium_api_development/)) and creating a c-module for Pycardium ([Guide...A module to access the shitty addon connector. This requires adding the necessary calls to Epicardium API ([Guide](https://card10.badge.events.ccc.de/en/firmware/epicardium_api_development/)) and creating a c-module for Pycardium ([Guide](https://card10.badge.events.ccc.de/en/firmware/pycardium_modules/)).
This includes:
- The i2c bus, ideally in a way that can be used by existing python driver libraries. (Ref [`lib/micropython/micropython/extmod/machine_i2c.c`](https://github.com/micropython/micropython/blob/master/extmod/machine_i2c.c))
- The two GPIOshttps://git.flow3r.garden/card10/firmware/-/issues/19MTP Implementation2019-08-18T12:29:23Zrahixcard10@rahix.deMTP ImplementationRight now, the only way to access the external flash from the host is using the bootloader. Epicardium should, additionally to the CDC ACM, export an MTP device to allow editing files.
It has to be MTP and can't be a simple block stora...Right now, the only way to access the external flash from the host is using the bootloader. Epicardium should, additionally to the CDC ACM, export an MTP device to allow editing files.
It has to be MTP and can't be a simple block storage, because otherwise we cannot synchronize file accesses from the outside and from the inside.https://git.flow3r.garden/card10/firmware/-/issues/18Improve BMA400 module2019-09-14T18:06:26Zrahixcard10@rahix.deImprove BMA400 moduleThere is a barebones BMA400 module available in the `rahix/bma400` branch. This module needs to be extended to contain more of the functionality of the chip.
It also has a bug which is the first reading returning an error as the chip i...There is a barebones BMA400 module available in the `rahix/bma400` branch. This module needs to be extended to contain more of the functionality of the chip.
It also has a bug which is the first reading returning an error as the chip isn't yet initialized (it takes some time to do so).https://git.flow3r.garden/card10/firmware/-/issues/12STREX/LDREX instead of Semaphore2019-07-07T11:54:57Zrahixcard10@rahix.deSTREX/LDREX instead of Semaphore- Replace current semaphore API implementation with one based on STREX/LDREX.
- http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dht0008a/ch01s02s01.html
- Measure performance- Replace current semaphore API implementation with one based on STREX/LDREX.
- http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dht0008a/ch01s02s01.html
- Measure performancehttps://git.flow3r.garden/card10/firmware/-/issues/7BLE mesh capability2019-10-04T12:03:39Zch3BLE mesh capabilityGet the bluetooth LE module to form meshes with other card10s.Get the bluetooth LE module to form meshes with other card10s.https://git.flow3r.garden/card10/firmware/-/issues/240Update Micropython to fix GCC 12 errors2023-12-05T20:52:41ZFrançois RevolUpdate Micropython to fix GCC 12 errorsTrying to build on a recent Debian Sid with GCC 12.3.1 I get an error:
```
../py/stackctrl.c:32:32: error: storing the address of local variable ‘stack_dummy’ in ‘mp_state_ctx.thread.stack_top’ [-Werror=dangling-pointer=]
32 | MP_...Trying to build on a recent Debian Sid with GCC 12.3.1 I get an error:
```
../py/stackctrl.c:32:32: error: storing the address of local variable ‘stack_dummy’ in ‘mp_state_ctx.thread.stack_top’ [-Werror=dangling-pointer=]
32 | MP_STATE_THREAD(stack_top) = (char *)&stack_dummy;
../py/stackctrl.c:31:18: note: ‘stack_dummy’ declared here
31 | volatile int stack_dummy;
| ^~~~~~~~~~~
```
This was [fixed in Micropython upstream](https://github.com/micropython/micropython/commit/f1c6cb7725960487195daa5c5c196fd8d3563811).
Applying the patch manually on the submodule brings another error:
```
main.c:342:6: error: conflicting types for ‘mp_import_stat’ due to enum/integer mismatch; have ‘uint(const char *)’ {aka ‘unsigned int(const char *)’} [-Werror=enum-int-mismatch]
342 | uint mp_import_stat(const char *path) {
| ^~~~~~~~~~~~~~
```
… which I supposed was probably fixed too upstream.https://git.flow3r.garden/card10/firmware/-/issues/235xeyes: Rewrite using new CTX API2021-10-29T20:10:38Zschneiderxeyes: Rewrite using new CTX APIhttps://git.flow3r.garden/card10/firmware/-/issues/234Pycardium time module does not update time if time zone is changed until inte...2021-09-19T11:02:23ZschneiderPycardium time module does not update time if time zone is changed until interpreter is restartedhttps://git.flow3r.garden/card10/firmware/-/issues/233Follow-up from "Dynamically scale system clock based on load"2021-09-19T10:33:39Zrahixcard10@rahix.deFollow-up from "Dynamically scale system clock based on load"The following discussion from !481 should be addressed:
- [ ] @rahix started a [discussion](https://git.card10.badge.events.ccc.de/card10/firmware/-/merge_requests/481#note_8674):
> In this implementation, we have a kind of two-la...The following discussion from !481 should be addressed:
- [ ] @rahix started a [discussion](https://git.card10.badge.events.ccc.de/card10/firmware/-/merge_requests/481#note_8674):
> In this implementation, we have a kind of two-layer tickless idle implementation. First, the `portSUPPRESS_TICKS_AND_SLEEP()` implementation from the FreeRTOS Cortex-M4 port switches the systick to a lower speed when entering tickless idle. Then we use its hooks (`configPRE_SLEEP_PROCESSING()`) to implement our own tickless idle which kind of undoes the systick work from the FreeRTOS port.
>
> Instead, from looking at <https://www.freertos.org/low-power-tickless-rtos.html> we can just drop the FreeRTOS port code entirely and implement `portSUPPRESS_TICKS_AND_SLEEP()` directly. This reduces the amount of useless work done, allows us to theoretically sleep for as long as we want, and de-clutters the codepaths in our sleep routine.https://git.flow3r.garden/card10/firmware/-/issues/229Consider support via gadgetbridge2021-01-09T16:21:09ZschneiderConsider support via gadgetbridgehttps://gadgetbridge.org/ offers support for a few interesting use-cases on Android for a multitude of BLE devices:
https://codeberg.org/Freeyourgadget/Gadgetbridge/src/branch/master/FEATURES.md
Example support for Pebble watches:
htt...https://gadgetbridge.org/ offers support for a few interesting use-cases on Android for a multitude of BLE devices:
https://codeberg.org/Freeyourgadget/Gadgetbridge/src/branch/master/FEATURES.md
Example support for Pebble watches:
https://codeberg.org/Freeyourgadget/Gadgetbridge/src/branch/master/app/src/main/java/nodomain/freeyourgadget/gadgetbridge/devices/pebblehttps://git.flow3r.garden/card10/firmware/-/issues/224Exposure Notifications App tries to run with BLE not enabled.2021-01-06T23:41:40ZPhilip StewartExposure Notifications App tries to run with BLE not enabled.If you open the Exposure Notification App without BLE enabled the app runs and silently fails.
Can we add a a message if BLE is off?If you open the Exposure Notification App without BLE enabled the app runs and silently fails.
Can we add a a message if BLE is off?https://git.flow3r.garden/card10/firmware/-/issues/223FreeRTOS exception waking the MAX86150 task2020-12-26T15:53:54ZschneiderFreeRTOS exception waking the MAX86150 taskHappened after using the MAX86150 for a few hours:
```
2020-12-25 12:12:56.573 --- SYSTEM PANIC ---
2020-12-25 12:12:56.574 --- ---
2020-12-25 12:12:56.577 --- ---
2020-12...Happened after using the MAX86150 for a few hours:
```
2020-12-25 12:12:56.573 --- SYSTEM PANIC ---
2020-12-25 12:12:56.574 --- ---
2020-12-25 12:12:56.577 --- ---
2020-12-25 12:12:56.581 A fatal error occured:
2020-12-25 12:12:56.582 Assertion failure:
2020-12-25 12:12:56.589 "( ( &( pxTCB->xEventListItem ) )->pvContainer ) == ((void *)0)"
2020-12-25 12:12:56.593 failed in "../lib/FreeRTOS/Source/tasks.c:5001",
2020-12-25 12:12:56.597 function: vTaskNotifyGiveFromISR()
2020-12-25 12:12:56.598
2020-12-25 12:12:56.601 Firmware Version:
2020-12-25 12:12:56.602 v1.16-107-gad28755b-dirty
2020-12-25 12:12:56.605
2020-12-25 12:12:56.605 Stack Trace:
2020-12-25 12:12:56.606 0x10013e07
2020-12-25 12:12:56.609
2020-12-25 12:12:56.613 Please report this error to the card10 firmware team!
2020-12-25 12:12:56.617 -> https://git.card10.badge.events.ccc.de/card10/firmware/issues/new <-
2020-12-25 12:12:56.621 --- ====== ===== ---
```
FreeRTOS code:
```c
void vTaskNotifyGiveFromISR( TaskHandle_t xTaskToNotify, BaseType_t *pxHigherPriorityTaskWoken )
{
TCB_t * pxTCB;
uint8_t ucOriginalNotifyState;
UBaseType_t uxSavedInterruptStatus;
» configASSERT( xTaskToNotify );
» /* RTOS ports that support interrupt nesting have the concept of a
» maximum»system call (or maximum API call) interrupt priority.
» Interrupts that are»above the maximum system call priority are keep
» permanently enabled, even when the RTOS kernel is in a critical section,
» but cannot make any calls to FreeRTOS API functions. If configASSERT()
» is defined in FreeRTOSConfig.h then
» portASSERT_IF_INTERRUPT_PRIORITY_INVALID() will result in an assertion
» failure if a FreeRTOS API function is called from an interrupt that has
» been assigned a priority above the configured maximum system call
» priority. Only FreeRTOS functions that end in FromISR can be called
» from interrupts»that have been assigned a priority at or (logically)
» below the maximum system call interrupt priority. FreeRTOS maintains a
» separate interrupt safe API to ensure interrupt entry is as fast and as
» simple as possible. More information (albeit Cortex-M specific) is
» provided on the following link:
» http://www.freertos.org/RTOS-Cortex-M3-M4.html */
» portASSERT_IF_INTERRUPT_PRIORITY_INVALID();
» pxTCB = xTaskToNotify;
» uxSavedInterruptStatus = portSET_INTERRUPT_MASK_FROM_ISR();
» {
» » ucOriginalNotifyState = pxTCB->ucNotifyState;
» » pxTCB->ucNotifyState = taskNOTIFICATION_RECEIVED;
» » /* 'Giving' is equivalent to incrementing a count in a counting
» » semaphore. */
» » ( pxTCB->ulNotifiedValue )++;
» » traceTASK_NOTIFY_GIVE_FROM_ISR();
» » /* If the task is in the blocked state specifically to wait for a
» » notification then unblock it now. */
» » if( ucOriginalNotifyState == taskWAITING_NOTIFICATION )
» » {
» » » /* The task should not have been on an event list. */
» » » configASSERT( listLIST_ITEM_CONTAINER( &( pxTCB->xEventListItem ) ) == NULL );
```
Random advice from the Internet: turn on `configUSE_LIST_DATA_INTEGRITY_CHECK_BYTES` as this looks like a memory corruption:
https://www.freertos.org/FreeRTOS_Support_Forum_Archive/July_2018/freertos_xTaskNotify_assertion_50220597j.htmlhttps://git.flow3r.garden/card10/firmware/-/issues/222Shutdown handler2020-12-20T15:58:37ZPixtxaShutdown handler- Would be nice to have one or two functions, that is/are called before standby (manual/empty batt) and gets a few seconds to run.
- I don't like the long, loud vibration, for me it could be much shorter. Baybe it also would be nice to b...- Would be nice to have one or two functions, that is/are called before standby (manual/empty batt) and gets a few seconds to run.
- I don't like the long, loud vibration, for me it could be much shorter. Baybe it also would be nice to blind an led, show a custumised shutdown screen, deinit hardware on or send a power off message to something
- Together with [Save data to ram](https://git.card10.badge.events.ccc.de/card10/firmware/-/issues/221) it may also be nice to save some data from ram to flash before going to sleep.https://git.flow3r.garden/card10/firmware/-/issues/221Save data to ram2020-12-20T15:56:30ZPixtxaSave data to ram- Save data to ram, so less flash writes are needed and data is not lost when app is changed
- Would be nice to write (maybe also read) data ofer ble from smartphone (spaceapi state, bitcoin price, outside temperature, …)
- keep data whe...- Save data to ram, so less flash writes are needed and data is not lost when app is changed
- Would be nice to write (maybe also read) data ofer ble from smartphone (spaceapi state, bitcoin price, outside temperature, …)
- keep data when sleeping, so nothing gets lost on empty batteryhttps://git.flow3r.garden/card10/firmware/-/issues/220non-blocking reads from serial?2020-11-14T11:16:35ZSven Knebelnon-blocking reads from serial?I'd like to write an app that talks to a program on my PC bidirectionally (kind of as a remote and utility display: send key presses and sensor values from the card10 to the PC, allow the PC to ask the card10 to blink LEDs/update display...I'd like to write an app that talks to a program on my PC bidirectionally (kind of as a remote and utility display: send key presses and sensor values from the card10 to the PC, allow the PC to ask the card10 to blink LEDs/update display contents). The obvious way seems to be the USB-serial.
With `print()` I can send text to the PC, but I would like a non-blocking way to check for data being sent from the PC, so that in an app main loop that reads sensors, controls LED blinking, ... this is just another step that checks for commands coming in.
I'm flexible in what this specifically looks like, some ideas:
* micropython seems to have a streams abstraction that maybe could wrap the serial input and seems to support this: http://docs.micropython.org/en/latest/library/uio.html (referenced from https://firmware.card10.badge.events.ccc.de/pycardium/stdlib.html#uio)
* it could be a function specific to the "standard output" matching `print()`, e.g. a `try_input()` that returns whatever is in the input buffer without waiting or a function to check if there is anything in the input buffer.
Possible workaround: I assume with `input()` I can do a blocking read of a line of text (haven't tested this yet), but that would rely on the PC-side constantly sending newlines to not block the app in that call, which doesn't seem ideal.https://git.flow3r.garden/card10/firmware/-/issues/219GDB: Consider disabling the watchdog when attaching2020-11-04T22:32:55ZschneiderGDB: Consider disabling the watchdog when attachingThe first time you attach to a running card10, the watchdog is still running. This prevents useful debugging until the first reset which then checks the debugger flag and does not initialize the watchdog again.
We could consider to eith...The first time you attach to a running card10, the watchdog is still running. This prevents useful debugging until the first reset which then checks the debugger flag and does not initialize the watchdog again.
We could consider to either
- Disable the watchdog in firmware as soon as we see an attached debugger.
or
- Disable the watchdog from GDB when attaching.https://git.flow3r.garden/card10/firmware/-/issues/216BHI accleration sensor sometimes does not send updates2020-11-04T22:46:57ZschneiderBHI accleration sensor sometimes does not send updatesI've modified menu.py and g-watch/__init_.py a bit:
- Reduce timeout in menu.py to 3 seconds
- Exit g-watch once a sample from the accelerometer comes in
This puts the card10 into a loop where it repeatedly starts the g-watch. After a...I've modified menu.py and g-watch/__init_.py a bit:
- Reduce timeout in menu.py to 3 seconds
- Exit g-watch once a sample from the accelerometer comes in
This puts the card10 into a loop where it repeatedly starts the g-watch. After a few hours it stops doing so because the g-watch does not receive new sensor data anymore.
Backtrace:
```
(gdb) task_backtrace bhi160_task_id
FPU is off
#0 0x10023f30 in vPortExitCritical () at ../lib/./FreeRTOS/./Source/portable/GCC/ARM_CM4F/portmacro.h:229
#1 0x100234de in ulTaskNotifyTake (xClearCountOnExit=536920208, xClearCountOnExit@entry=1, xTicksToWait=536920196, xTicksToWait@entry=2000) at ../lib/FreeRTOS/Source/tasks.c:4599
#2 0x100114bc in vBhi160Task (pvParameters=<optimized out>) at ../epicardium/modules/bhi.c:530
#3 0x10023e20 in ?? () at ../lib/FreeRTOS/Source/portable/GCC/ARM_CM4F/port.c:703
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
```https://git.flow3r.garden/card10/firmware/-/issues/214SpO2: Determine calibration factors for MAX861502023-04-17T09:53:13ZschneiderSpO2: Determine calibration factors for MAX86150!414 introduced a demo app for SpO2 estimation using the MAX86150. It's results for SpO2 are not reliable though.
https://git.card10.badge.events.ccc.de/card10/firmware/-/issues/196 discusses details of how SpO2 is estimated using these...!414 introduced a demo app for SpO2 estimation using the MAX86150. It's results for SpO2 are not reliable though.
https://git.card10.badge.events.ccc.de/card10/firmware/-/issues/196 discusses details of how SpO2 is estimated using these algorithms. We currently implement an algorithm from Maxim based on the code for their RD117 reference design. What we are missing at the moment are the calibration values for the MAX86150 to at least get somehow reasonable results.
![IMG_20200426_015712](/uploads/b3864c60254a484ea49d2dcf76b3f9fb/IMG_20200426_015712.jpg)
The estimated SpO2 values are generally too high. Heart rate seems to work if the finger is pressed on "correctly". I can imagine that it might be necessary to design a (printed) spacer around the sensor to have repeatable results.https://git.flow3r.garden/card10/firmware/-/issues/213Follow-up from "Pycardium Improvements"2021-11-16T22:40:21Zrahixcard10@rahix.deFollow-up from "Pycardium Improvements"The following discussion from !417 should be addressed:
- [ ] @schneider started a [discussion](https://git.card10.badge.events.ccc.de/card10/firmware/-/merge_requests/417#note_7950): (+1 comment)
> When pressing CTRL+C and then C...The following discussion from !417 should be addressed:
- [ ] @schneider started a [discussion](https://git.card10.badge.events.ccc.de/card10/firmware/-/merge_requests/417#note_7950): (+1 comment)
> When pressing CTRL+C and then CTRL+D one now ends up in the menu. I think before the main app was started again. Is that intended?
>
> I'm wondering if we can maybe make use of this: Allow the menu to react to cursor keys or present a small menu on the console as well. Would eliminate the need to press buttons during development.v1.19https://git.flow3r.garden/card10/firmware/-/issues/205Periodically re-seed CSPRNG2020-09-19T22:01:26ZschneiderPeriodically re-seed CSPRNGThe CSPRNG introduced with !399 is only seeded once during boot. It should be re-seeded periodically if possible.The CSPRNG introduced with !399 is only seeded once during boot. It should be re-seeded periodically if possible.