Core issueshttps://gitlab.laas.fr/owntech/power-api/core/-/issues2024-02-15T12:37:48Zhttps://gitlab.laas.fr/owntech/power-api/core/-/issues/75Error even after a first flash with bootloader2024-02-15T12:37:48ZThomas WalterError even after a first flash with bootloaderFlashing code with bootloader without pressing boot and reset button is not possible, got the following error:
`AVAILABLE: blackmagic, cmsis-dap, custom, jlink, mbed, stlink
CURRENT: upload_protocol = custom
upload_pre(["upload"], [".pi...Flashing code with bootloader without pressing boot and reset button is not possible, got the following error:
`AVAILABLE: blackmagic, cmsis-dap, custom, jlink, mbed, stlink
CURRENT: upload_protocol = custom
upload_pre(["upload"], [".pio\build\bootloader_serial\firmware.mcuboot.bin"])
Detecting Spin boards connected to host...
Board 1: Found Spin board on port COM38 with unique ID 4630500400360057
Uploading to board with ID 4630500400360057
Uploading .pio\build\bootloader_serial\firmware.mcuboot.bin
'MCUMGRPATH' n'est pas reconnu en tant que commande interne
ou externe, un programme ex\x82cutable ou un fichier de commandes.
*** [upload] Error 1`https://gitlab.laas.fr/owntech/power-api/core/-/issues/72Analog comm DTS fragment does not match TWIST default pinout.2024-01-23T10:26:46ZJean AlineiAnalog comm DTS fragment does not match TWIST default pinout.``` analog: analog-comm {
compatible = "adc-channels";
channel-name = "ANALOG_COMM";
default-gain = < 0x3f800000 >;
default-offset = < 0x0 >;
spin-pin = < 0x6 >;
analog-comm-adc4 {
io-channels = < &adc4 0x5 >;
}...``` analog: analog-comm {
compatible = "adc-channels";
channel-name = "ANALOG_COMM";
default-gain = < 0x3f800000 >;
default-offset = < 0x0 >;
spin-pin = < 0x6 >;
analog-comm-adc4 {
io-channels = < &adc4 0x5 >;
};
};```
spin-pin should be 35 (0x23)
default adc (without changing onboard solder jumpers) is adc2 ch5.
hence it should be `io-channels = < &adc2 0x5 >;` by default.https://gitlab.laas.fr/owntech/power-api/core/-/issues/71[Flash Memory] The flash memory address is wrong for the nucleo overlay2024-01-25T16:43:49ZLuiz Fernando Lavado Villa[Flash Memory] The flash memory address is wrong for the nucleo overlay**Description**
The nucleo overlay has the following dts code for its flash memory adresses.
```c
&flash0 {
/*
* For more information, see:
* http://docs.zephyrproject.org/latest/guides/dts/index.html#flash-partitions
*/
parti...**Description**
The nucleo overlay has the following dts code for its flash memory adresses.
```c
&flash0 {
/*
* For more information, see:
* http://docs.zephyrproject.org/latest/guides/dts/index.html#flash-partitions
*/
partitions {
/* We have to remove the partition defined in the board dts */
/delete-node/ partition@1f000;
app_partition: partition@0 {
label = "app";
reg = <0x00000 0x7F000>;
};
/* Set 4Kb of storage at the end of the 512Kb of flash */
storage_partition: partition@79000 {
label = "storage";
reg = <0x79000 0x1000>;
};
};
};
```
The address in the storage partition is wrong.
**Correction**
The address must be replaced by :
It should be replace by:
```c
app_partition: partition@0 {
label = "app";
reg = <0x00000 0x7F000>;
};
/* Set 4Kb of storage at the end of the 512Kb of flash */
storage_partition: partition@7F000 {
label = "storage";
reg = <0x7F000 0x1000>;
};
```Clément FoucherClément Foucherhttps://gitlab.laas.fr/owntech/power-api/core/-/issues/70Problem with adcTriggerSoftwareConversion ?2024-01-12T10:52:01ZGuillaume ArthaudProblem with adcTriggerSoftwareConversion ?hello,
![image.png](/uploads/db86d795a9d2e17595a975af45681d7a/image.png)
I'm trying to read samples in my program. This works 2 times in a row but not 3 or more times. This is what I get
```plaintext
data 3298.000000
data 3299.000000...hello,
![image.png](/uploads/db86d795a9d2e17595a975af45681d7a/image.png)
I'm trying to read samples in my program. This works 2 times in a row but not 3 or more times. This is what I get
```plaintext
data 3298.000000
data 3299.000000
data -10000.000000
data -10000.000000
data -10000.000000
```
Am I doing something wrong?Clément FoucherClément Foucherhttps://gitlab.laas.fr/owntech/power-api/core/-/issues/69hrtim.yaml does not describe dts properties.2024-01-10T14:10:42ZJean Alineihrtim.yaml does not describe dts properties.At the moment the yaml file doesn't describe hrtim dts properties.At the moment the yaml file doesn't describe hrtim dts properties.Clément FoucherClément Foucherhttps://gitlab.laas.fr/owntech/power-api/core/-/issues/68HRTIM1 peripheral in spin.dts is defined but not used.2024-01-10T14:26:15ZJean AlineiHRTIM1 peripheral in spin.dts is defined but not used.While trying to add sync_in and sync_out subnodes to hrtim1 dts definition in spin.dts, I realized that at the moment hrtim.dtsi fragment is defined but not used.
Indeed ATM, hrtim.c file redefine everything it needs to configure hrtim...While trying to add sync_in and sync_out subnodes to hrtim1 dts definition in spin.dts, I realized that at the moment hrtim.dtsi fragment is defined but not used.
Indeed ATM, hrtim.c file redefine everything it needs to configure hrtim using LL calls, not even using zephyr pinctrl-0 property.
It would be interesting to define child nodes to hrtim1 dts node, one per timing unit.
As such we would have pinctrl-0 properties for each timing unit.
Interupts properties could also be spread inside timing unit child nodes.
Sync_in and Sync_out could also be defined as child nodes of hrtim1, in order to have pinctrl compatibility and supress most of sync_master_init() / sync_slave_init() LL calls.
pinctrl-1 could be used to match different versions of shields, so that sync_in sync_out would be remapped depending on shield pinout.
I would love to have your opinion on that @afarahhass @cfoucherAyoub Farah HassanAyoub Farah Hassanhttps://gitlab.laas.fr/owntech/power-api/core/-/issues/67[power] eliminate All from function calls to harmonize function naming2023-12-22T07:31:18ZLuiz Fernando Lavado Villa[power] eliminate All from function calls to harmonize function naming**Description**
Functions in the `power` api are split evenly between `All` and `Leg`. This is a potential problem as it is unclear from the function names what is "All".
**Correction**
Either:
- [ ] Eliminate the All functions and ...**Description**
Functions in the `power` api are split evenly between `All` and `Leg`. This is a potential problem as it is unclear from the function names what is "All".
**Correction**
Either:
- [ ] Eliminate the All functions and create an equivalent behavior using the Leg functions
- [ ] Rename the All functions to AllLegs which makes it more readableRelease v1.0.0Ayoub Farah HassanAyoub Farah Hassanhttps://gitlab.laas.fr/owntech/power-api/core/-/issues/66wiki update for hrtim evt2023-12-20T10:30:39ZRégis Ruellandwiki update for hrtim evtThe events to trig the adc are not described.
https://gitlab.laas.fr/owntech/power-api/core/-/wikis/Modules/Data%20acquisition#default-configuration-for-the-twist-shield
Trigger sources are
* evt1 on HRTIM1 for ADC 1
* evt3 on HRTIM1 f...The events to trig the adc are not described.
https://gitlab.laas.fr/owntech/power-api/core/-/wikis/Modules/Data%20acquisition#default-configuration-for-the-twist-shield
Trigger sources are
* evt1 on HRTIM1 for ADC 1
* evt3 on HRTIM1 for ADC 2
evt1, evt2, evt3, evt4: event trig when the hrtim counter reach some threshold.
* evt1 in center align mode is when TIMER A has reached its peak.
* evt3 is center align mode is when TIMER C has reached its peak.
By default TIMER A and TIMER C are not phase-shifted.Clément FoucherClément Foucherhttps://gitlab.laas.fr/owntech/power-api/core/-/issues/65[TWIST 1.3] hwConfig.setNgndOn() doesn't work2023-11-09T13:41:15ZThomas Walter[TWIST 1.3] hwConfig.setNgndOn() doesn't workOn TWIST 1.3 hwConfig.setNgndOn() doesn't work as it is the incorrect PIN in device tree.
In device tree, change gpiob 11 to gpioc 6 :
```
Actual code:
/ {
ngnd: ngnd-switch {
compatible = "gpio-device";
ngnd-gpio-pin {
gp...On TWIST 1.3 hwConfig.setNgndOn() doesn't work as it is the incorrect PIN in device tree.
In device tree, change gpiob 11 to gpioc 6 :
```
Actual code:
/ {
ngnd: ngnd-switch {
compatible = "gpio-device";
ngnd-gpio-pin {
gpios = <&gpiob 11 GPIO_ACTIVE_HIGH>;
label = "Neutral to GND shunt";
};
};
Correct code:
/ {
ngnd: ngnd-switch {
compatible = "gpio-device";
ngnd-gpio-pin {
gpios = <&gpioc 6 GPIO_ACTIVE_HIGH>;
label = "Neutral to GND shunt";
};
};https://gitlab.laas.fr/owntech/power-api/core/-/issues/64Standardization of modules names2023-10-26T09:10:20ZMathilde LonguetStandardization of modules namesThe following modules do not contain either "api" or "driver" in their name :
scheduling, hardware_configuration, data_acquisition, communicationThe following modules do not contain either "api" or "driver" in their name :
scheduling, hardware_configuration, data_acquisition, communicationhttps://gitlab.laas.fr/owntech/power-api/core/-/issues/59New board : OWNVERTER_V_0_92023-08-21T10:43:07ZThomas WalterNew board : OWNVERTER_V_0_9As we developped a new board OWNVERTER_V_0_9, code must be updated with at least the followings:
- A line OWNVERTER_V_0_9 should be added to the the hardware_version_t enum in the file HardwareConfiguration.h
- Update PB11 assignation....As we developped a new board OWNVERTER_V_0_9, code must be updated with at least the followings:
- A line OWNVERTER_V_0_9 should be added to the the hardware_version_t enum in the file HardwareConfiguration.h
- Update PB11 assignation. It is now an ADC input (ILOW3) (on twist it is a DAC output).https://gitlab.laas.fr/owntech/power-api/core/-/issues/58New board : TWIST_V_1_32023-08-28T08:40:20ZThomas WalterNew board : TWIST_V_1_3As we developped a new board TWIST V_1_3, code must be updated with at least the followings:
- A line TWIST_V_1_3 should be added to the the hardware_version_t enum in the file HardwareConfiguration.h
- HRTIM inversion should be uninver...As we developped a new board TWIST V_1_3, code must be updated with at least the followings:
- A line TWIST_V_1_3 should be added to the the hardware_version_t enum in the file HardwareConfiguration.h
- HRTIM inversion should be uninverted compared to TWIST 1.2 as they are now correctly routed (hint: use same configuration as SPIN_V_0_9)https://gitlab.laas.fr/owntech/power-api/core/-/issues/57[Issue] The Frequency does not work below a certain threshold2023-07-17T12:44:32ZLuiz Fernando Lavado Villa[Issue] The Frequency does not work below a certain threshold**Context**
When testing the use of multiple frequencies with the OwnVerter, lower than 50kHz were not generated.
**Description**
Frequency generation with the OwnVerter (and hence the SPIN) does not go below 50kHz. This is due to an ...**Context**
When testing the use of multiple frequencies with the OwnVerter, lower than 50kHz were not generated.
**Description**
Frequency generation with the OwnVerter (and hence the SPIN) does not go below 50kHz. This is due to an issue at the leg driver level.
**Action**
Verify the hrtim leg driver and make it so that the frequency can be lowered all the way down to 1 Hz.Have a generic hrtim implementationLuiz Fernando Lavado VillaLuiz Fernando Lavado Villahttps://gitlab.laas.fr/owntech/power-api/core/-/issues/52Zephyr doesn't have a function that return the number of bytes in the input s...2023-03-28T08:56:48ZThomas WalterZephyr doesn't have a function that return the number of bytes in the input serial bufferThe feature updateCoefficient requires an end of line character.
The actual code handles LF or CR but doesn't handle CRLF.
In order to hande CRLF, a function that return the number of bytes in the input serial buffer (like serial.Availab...The feature updateCoefficient requires an end of line character.
The actual code handles LF or CR but doesn't handle CRLF.
In order to hande CRLF, a function that return the number of bytes in the input serial buffer (like serial.Available in arduino) is required.
After looking in the console.h and the zephyr documentation it appears that the only way to do so is to use a UART instance, detailled here :
https://docs.zephyrproject.org/latest/hardware/peripherals/uart.html#uart-polling-api
An example of NOT TESTED code generated with chatGPT :
```
#include <zephyr.h>
#include <device.h>
#include <drivers/uart.h>
#define UART_DEVICE_NAME "UART_0"
void main(void)
{
struct device *uart_dev;
bool data_ready;
uint8_t buffer[32];
uart_dev = device_get_binding(UART_DEVICE_NAME);
if (!uart_dev) {
printk("Failed to get UART device\n");
return;
}
data_ready = uart_irq_rx_ready(uart_dev);
if (data_ready) {
int bytes_read = uart_fifo_read(uart_dev, buffer, sizeof(buffer));
printk("Read %d bytes from the serial port\n", bytes_read);
} else {
printk("No data available in the serial buffer\n");
}
}
```https://gitlab.laas.fr/owntech/power-api/core/-/issues/51Being able to modify the trigger instant of the adc measure2023-03-28T14:29:31ZThomas WalterBeing able to modify the trigger instant of the adc measureIn order to improve the accuracy of current measurement, we need to be able to modify the triggering moment, done by the HRTIM, of the ADC.
The code to do so is in the commit tagged here :
https://gitlab.laas.fr/twalter/core/-/tags/Modi...In order to improve the accuracy of current measurement, we need to be able to modify the triggering moment, done by the HRTIM, of the ADC.
The code to do so is in the commit tagged here :
https://gitlab.laas.fr/twalter/core/-/tags/Modify_Adc_Trigger_instant_issue
This issue contains 3 tasks :
1- Rebase the code with the newest version of core as it has been developped from an older version of core.
2- Check if the code respects all development rules. If not, rewrite it so it respects the rules.
3- When steps 1 and 2 are done, open a PR.https://gitlab.laas.fr/owntech/power-api/core/-/issues/48[Scheduling] Implementing RMS2023-09-27T06:39:16ZJean Alinei[Scheduling] Implementing RMSFor now RMS is not supported by zephyr.
All tests using OS features have failed to provide a valid time overhead.
After a lot of discussions it still seems to be the best scheduling architecture.For now RMS is not supported by zephyr.
All tests using OS features have failed to provide a valid time overhead.
After a lot of discussions it still seems to be the best scheduling architecture.Jean AlineiJean Alineihttps://gitlab.laas.fr/owntech/power-api/core/-/issues/47[Comments] A lot of module do not have javadocs comment snippets2023-12-22T07:33:24ZJean Alinei[Comments] A lot of module do not have javadocs comment snippetsIt is important to add comment snippet in order to have correct tooltip hints for each public function and preferably also for the corresponding private function.It is important to add comment snippet in order to have correct tooltip hints for each public function and preferably also for the corresponding private function.https://gitlab.laas.fr/owntech/power-api/core/-/issues/46OwnTech plugin for VS Code2023-10-10T08:02:23ZClément FoucherOwnTech plugin for VS CodeZephyr on PlatformIO seems to be dead: PlatformIO did not integrate Zephyr updates for a long time now and Zephyr removed PlatformIO from its official documentation. It seems this is time to abandon PlatformIO from our flow.
This issue ...Zephyr on PlatformIO seems to be dead: PlatformIO did not integrate Zephyr updates for a long time now and Zephyr removed PlatformIO from its official documentation. It seems this is time to abandon PlatformIO from our flow.
This issue is the place to indicate our requirements for a future evolution of our base flow.Clément FoucherClément Foucherhttps://gitlab.laas.fr/owntech/power-api/core/-/issues/45[Syntax] Some modules adopts camel case style while some others have snake ca...2023-07-10T09:39:30ZJean Alinei[Syntax] Some modules adopts camel case style while some others have snake case styleAs per title, we should define a clear coding style for both public and private functions.As per title, we should define a clear coding style for both public and private functions.https://gitlab.laas.fr/owntech/power-api/core/-/issues/44Allocate DMA channels dynamically2023-10-10T07:33:50ZClément FoucherAllocate DMA channels dynamicallyInstead of relying on arbitrary selected DMA channels for various uses, which requires us to maintain a list of these channels, we could allocate channels dynamically. There exist a function in Zephyr to do so, `dma_request_channel`, but...Instead of relying on arbitrary selected DMA channels for various uses, which requires us to maintain a list of these channels, we could allocate channels dynamically. There exist a function in Zephyr to do so, `dma_request_channel`, but it fails when called because of DMA_MAGIC not being set.
Information about DMA_MAGIC is:
```c
/* magic code to identify context content */
#define DMA_MAGIC 0x47494749
```
This is the kind of stuff we can test again when we move to Zephyr 3.
Code used for the test:
```c
// Obtain DMA channel for the ADC
enum dma_channel_filter filter = DMA_CHANNEL_NORMAL;
int channel = dma_request_channel(dma1, (void*)&filter);
printk("%d\n", channel);
__ASSERT(channel > 0, "Error! No DMA channel available.");
```Clément FoucherClément Foucher