chibios / chibios-contrib Goto Github PK

Hi guys

I decided to evaluate Segger J-Link, and tested the example in the ChibiOS-Contrib section

However, when I run it in the debugger; it is as if ChibiOS thinks it is running in a thread contexts it freezes at chSysHalt("SV#6")

Clearly I can see in the debugger that I am in a DMA ISR , which invokes macro CH_CFG_IRQ_PROLOGUE_HOOK() that is delegated to SEGGER_SYSVIEW_RecordEnterISR() method
Here is a picture

Therefore, I wonder if this is a bug, or my J-Link hardware is bad, or I did something wrong?

Many thanks in advance.

Hello!

I am porting my application from Chibios 17 to 18 and I use the FSMC driver.

Problem:
The new build system catches ALLSRC and ALLINC paths for compilation. The "platform.mk" file of the contrib branch first includes the original "platform.mk" and then adds its own sources to

PLATFORMSRC
PLATFORMINC

However, these are not used by the makefile anymore.

In my instance, I could fix it by changing the variable names, to which the paths are appended, like this:

include ${CHIBIOS}/os/hal/ports/STM32/STM32F7xx/platform.mk

ALLSCR += ${CHIBIOS_CONTRIB}/os/hal/ports/STM32/LLD/FSMCv1/hal_fsmc.c \
               ${CHIBIOS_CONTRIB}/os/hal/ports/STM32/LLD/FSMCv1/hal_nand_lld.c \
               ${CHIBIOS_CONTRIB}/os/hal/ports/STM32/LLD/FSMCv1/hal_fsmc_sram.c \
               ${CHIBIOS_CONTRIB}/os/hal/src/hal_fsmc_sdram.c

ALLINC += ${CHIBIOS_CONTRIB}/os/hal/ports/STM32/LLD/FSMCv1 \
               ${CHIBIOS_CONTRIB}/os/hal/ports/STM32/LLD

but this will break compilation with ChibiOS 17.

Any comments on what would be the best solution?

Adrian

Hello,
Starting from ChibiOS 17.6.4 and ChibiOS 18.2.0 (current trunk) OpenOCD launch configuration will be placed under ($CHIBIOS)/tools/eclipse/debug/

This means that to see Launch configuration under the menu external tools of Eclipse the "ChibiOS Whole Tree" project shall be imported into workspace and be opened.

As each TIVA demo has a copy of the "OpenOCD on ICDI (prompts for .cfg target configuration)" under its debug folder, the external tools submenu is overfilled with replies of the same launch configuration.

I have committed a copy of this debug configuration under the tools folder so these extra file could now be removed.
Ciao,
RM

In the QEI driver, the qeiUpdate function returns the counter delta from the last reading, which when the counter is wrapping result in a huge delta.

The testhal example (testhal/STM32/STM32F4xx/USB_HOST) for the USB host functionality does not seem to work on the STM32F4 DISCOVERY board (which is the hardware platform this example was originally written for).

What I'm seeing specifically is freezing of the program. One place this occurs in is _usbh_dbgf(). If I comment out those calls in the example, the processor successfully enters the main loop without issues, however as soon as I plug a USB device into the port the program freezes again. Unfortunately, digging deeper is a bit outside of my wheelhouse. I tried debugging through gdb over the ST-Link, but didn't really get anywhere.

Through the magic of git bisect I was able to determine that the testhal example has been broken since commit 958059c (introduced during the 20.3.x cycle). Prior to that everything seems to work as expected.

My guess is that the USBH LLD itself is broken and not the testhal example itself, but I can't verify this as I don't have any other code using the usb host functionality.

Background: My plan is to use the USB host functionality in QMK on the OTG2 of an STM32F446. After writing the initial QMK code I was not able to make it work, so I decided to go back trying out other people's code (the testhal example) in case I made a mistake.

Additional information:

• ChibiOS-contrib a224be1 (chibios-21.11.x)
• ChibiOS ChibiOS/ChibiOS@c9f4b3a (stable_21.11.x)
• Hardware: STM32F4 Discovery (MB8997E)

Applying the suggestion in #267 did not fix the problem.

Hi all,

I think a bug was introduced in commit f014b8d. I'm not 100% sure, and would appreciate some input from the author @josesimoes. Originally, _scsi_perform_transaction returned MSD_RESULT_FAILED when transaction->csw_status was CSW_STATUS_FAILED, after performing a SCSI Request Sense. The commit introduced line 520, which would cause _scsi_perform_transaction to return MSD_RESULT_OK if the request sense was successful, even if the transaction was not carried out. I think the original code is correct. José, any comments?

Thanks,
Diego.

Hello,
I am using the HAL of ChibiOS but not the RT part because I do not need a RTOS for my projet.
I am using your QEI driver. It works nice but I had to move some:

#include "ch.h"

after the line checking if the module is used. Ex:

#if (HAL_USE_TIMCAP == TRUE) || defined(__DOXYGEN__)

The files I had to modify:

• os/hal/include/hal_eeprom.h
• os/hal/include/hal_timcap.h
• os/hal/ports/STM32/LLD/DMA2Dv1/hal_stm32_dma2d.c
• os/hal/ports/STM32/LLD/LTDCv1/hal_stm32_ltdc.c
• os/hal/ports/STM32/LLD/TIMv1/hal_timcap_lld.c

So if the RT part is really needed for these components, maybe it will be possible to move the #include after the check is the module is used in order to allow users to use other modules without the RT part of ChibiOS.

Thanks.

Hi,

there is a problem with CRC Driver (community) with CRC_USE_DMA=TRUE,
driver does not work correctly with buffer more 256k due to DMA limitation.
ChibiOS version - 17.6.3

Hey there :)
I've begun work on support for the Nuvoton NUC126 family.

I'm basing my work on the current NUC123 code.
Will update with a PR, hopefully in a few days.

https://www.raspberrypi.org/blog/raspberry-pi-silicon-pico-now-on-sale/

Support here for this is a pre-req for QMK (qmk/qmk_firmware#11649)

As of today:

https://github.com/ChibiOS/ChibiOS-Contrib fails tests, no changes for a few months
https://github.com/ChibiOS/ChibiOS-Contrib/tree/chibios-20.3.x fails tests, no changes for a few months
https://github.com/ChibiOS/ChibiOS-Contrib/commits/chibios-21.6.x fails tests, no changes for a few months

Is build system broken or is not just not important?

ChibiOS has released a stable 21.11.x branch. Is there a roadmap on a -Contrib version?

It's not a bug, it's a feature request to add usb host support for stm32f1xx (stm32f105/107 supports USB OTG FS)

When I used mx2board.py to convert a .ioc file from an STM32F7 with an FMC memory controller peripheral, I found

1. that the FMC was missing.
2. Then I discovered that the STM32F769(G-I)T.xml file contains records for e.g.
   FMC_A4
   and
   FMC_D4
   for pin PE7

but the .ioc file calls the pin
FMC_D4_A4

I changed the code to match for FMC and modify the pin names in the Python code for the FMC
so that FMC_D0_A0 is mapped into FMC_D0

-- code snippet with changes
if prop_value.startswith('ADC') \
or 'DAC' in prop_value \
or 'OSC' in prop_value:
pads[pad_port][pad_num]["MODER"] = PIN_MODE_ANALOG
# Changes here to deal with the FMC
elif prop_value.startswith('FMC'):
pads[pad_port][pad_num]["OSPEEDR"] = PIN_OSPEED_HIGH
# There is an issue with the STM XML files: they list FMC_D0 and FMC_A0 but
# in fact the .ioc file contains FMC_D0_A0 as the prop_value
# so the idea here is to split the string then recombine the parts
# into a pattern the XML file contains
split_prop = prop_value.split("_")
pads[pad_port][pad_num]["SIGNAL"] = split_prop[0]+"_"+split_prop[1]
pads[pad_port][pad_num]["MODER"] = PIN_MODE_ALTERNATE
#end of changes to deal with FMC
elif 'GPIO_Output' == prop_value:
pads[pad_port][pad_num]["MODER"] = PIN_MODE_OUTPUT
elif 'GPIO_Input' == prop_value:
pads[pad_port][pad_num]["MODER"] = PIN_MODE_INPUT
-- end of snippet

For performance it would be good to use DMA in the USB host driver.

Currently the STM USB host library doesn't support hubs, and the ChibiOS-Contrib USB host driver doesn't use DMA, so it would be very valuable to have DMA in here, so one doesn't have to choose between performance and hub support.

I was having issues with SonixQMK on my Keychron K3V2, when i plug the keyboard to my machine it was sometimes not working completely and i had to replug it several times to get it to work.

While I was investigating this, I found that commit ff55126 has broken this keyboards usb behaviour. It is consistently working correctly on d5e4fb2 but it does not work on ff55126.

Please do investigate further.

http://www.nuvoton.com.cn/products/microcontrollers/arm-cortex-m0-mcus/nuc121-125-series/
and datasheet
https://datasheetspdf.com/pdf/1134277/nuvoton/NUC121/1

Hi All,

First thing, I want to thank @dismirlian for his work on the USB Host driver thus far - it is really a great improvement over other options in this space for STM32, and I know it is no small task to write such a complex piece of code.

I have been experimenting with the latest revisions of the driver on here and it looks promising - I am hoping to use it as a replacement to the HCC USB Host stack in an ongoing project where we are encountering issues due to some design flaws in HCC's stack.

Couple things that I have encountered so far:

• no support for out-of-tree drivers
  • need to modify the chibios-contrib code base itself to add any project specific drivers that may not be suitable for inclusion in chibios-contrib
• PTXFE not implemented, meaning ISO/INT OUT transfers result in IRQ storm and lock up system
  • copying implementation from NPTXFE seems to work for at least INT OUT transfers so far - once I confirm ISO works I will be happy to submit a PR

Diego, have you given any thought to potential API's for better control over the enumeration process without modifying the chibios-contrib code base itself? I have hacked together some hooks to get up and running for now, but it is by no means pretty. I can try to clean up what I have so far and publish it for review if that helps.

I am idling on #chibios @ freenode if anyone wants to discus these topics.

Hi,

We have recently forked your repo to add support to the Decawave DWM1001 (it has one embedded nRF52832) for a student's project.

So far, all the tests work with ChibiOS. However, I have spent the last couple of days trying to make the radio test (https://github.com/ChibiOS/ChibiOS-Contrib/tree/chibios-20.3.x/testhal/NRF52/NRF52832/RADIO-ESB ) work.

I flashed the binary from that main (the only modifications are that LEDs and buttons are defined differently, you can find it here https://github.com/UCM-237/Distributed_localization_DWM1001/blob/radio_test/src/main.c ), and I can see the following:

With ack, the TX_FAILED event is triggered since there is no ack from the other radio.
With noack, the TX_SUCCESS event is triggered. However, the other radio never receives anything (the event or even the interruption is not triggered).

I wonder whether there is "this special" detail that I maybe overlook, such as timers incompatibilities or similar.
By the way, I have to set tx_payload.length = 32 , otherwise, if I use this line from the original code
https://github.com/UCM-237/Distributed_localization_DWM1001/blob/radio_test/src/main.c#L100 it does not work (I did not check with a debugger what is the result of this operation, but not TX event is triggered).

Thanks a lot in advance.

edit

I forgot to add that in this example, I am using the same mcuconf.cfg, hal.cfg, hal_community and ch.cfg as in the original test.

QEI define a callback type, but STM32 implementation doesn't make use of it.
Would it be possible to have a callback triggered when values change?

I've recently run into a bug while trying to use both of the analog comparators on STM32F37.
The problem seems to be that on STM32F37 and STM32F38 COMP1 and COMP2 share the same 32-bit register COMP_CSR, so configuring the second comparator affects the configuration of the first one.

Here's an example:

Breakpoint 1: COMP1 configured.

Breakpoint 3: Enabling COMP2 discards the COMP1 configuration.

I was able to fix this by adding some preprocessor directives to the os/hal/ports/STM32/LLD/COMPv1/hal_comp_lld.c, will create a pull request later.

ChibiOS version: stable_20.3.x
Compiler: arm-none-eabi-gcc (10.3-2021.10)
Platform and board: STM32F373CC (custom board)

Now that ALLCSRC and ALLINC are defined, the platform.mk files should not append to PLATFORMSRC/INC. They should either create a new variable, or redefine PLATFORMSRC/INC, and then add the filenames to ALLCSRC, and ALLINC.

Hi IMHO,
Within the functions such as nandReadPageWhole(), nandp->config is defined as a constant pointer and would need the same to be handled correctly.

Code:
NANDConfig *cfg = nandp->config;

Should change to :
const NANDConfig *cfg = nandp->config;

in 7 functions in this file.

Thanks,
Abdulqadir Shabbir

Here is the details of this MCU: http://www.sonix.com.tw/article-en-4336-30356

Thanks for help!

First of all,
Thanks to @barthess, @fpoussin, and everyone else who contributed to providing NAND flash driver.
I recently tried moving from 18.2.0 to 20.3.2 and had following issues:

1. For ChibiOS-Contrib/os/hal/include/hal_fsmc.h:37 => needs to include stm32f7x targets

2. Also line324 on the same file has a typo "STM32_NAND_USE_NAND1" instead of "STM32_NAND_USE_NAND2"

3. Should dmaStreamAlloc(nandp->dma, be=> nandp->dma = dmaStreamAlloc(STM32_NAND_DMA_STREAM,

If you guys deem it suitable, I can make these changes and do a pull request.

Thanks,
AQ

ChibiOS version: 20.3.2
Compiler: arm-none-eabi-gcc (7-2018-q2-update)(7.3.1)
Platform and board:STM32F723ZE (custom board)
Nature of the problem: Cannot compile
Failure mode: n/a

in the case where eeprom_write fails repeatedly __fitted_write will never increment the value given to its written parameter.

which in turn causes an infinite loop in write as shown below

eeprom_write simply passes on the return value from i2cMasterTransmitTimeout, which can return MSG_TIMEOUT if there is a timeout or MSG_RESET if an I2C bus error occurs.

The result is that if you have a mis-behaving eeprom, the software will deadlock.

In addition, if some transient error condition occurs, it would go unnoticed and result in very different data being written than expected - as well as read past end of buffer errors on bp since bp is incremented by len regardless of whether written gets incremented.

In short, the write method of the ee24xx driver is incredibly unreliable and has many bugs.
Quickly looking at the ee25xx driver (although I have not used it), the infinite loop issue was fixed, but the transient error issue still exists since the return value of __fitted_write is not checked every time it is called.

Hello.

Im working on a project with Chibios 18.2.x (origin/stable_18.2.x) and Chibios-Contrib (origin/chibios-17.6.x). The Makefile of my project includes theses .mk files:

# ChibiOS files
include $(CHIBIOS)/os/license/license.mk
include $(CHIBIOS)/os/common/startup/ARMCMx/compilers/GCC/mk/startup_stm32f0xx.mk
include $(CHIBIOS)/os/hal/ports/STM32/LLD/EXTIv1/driver.mk
include $(CHIBIOS)/os/hal/osal/rt/osal.mk
include $(CHIBIOS)/os/rt/rt.mk
include $(CHIBIOS)/os/common/ports/ARMCMx/compilers/GCC/mk/port_v6m.mk
# ChibiOS contrib files
include $(CHIBIOS_CONTRIB)/os/hal/hal.mk
include $(CHIBIOS_CONTRIB)/os/hal/ports/STM32/STM32F0xx/platform.mk
# ChibiOS project
include $(CHIBIOS_CONTRIB_PRJ/os/hal/boards/ST_STM32F072B_PRJ/board.mk

I'm getting some warnings when compiling ChibiOS-Contrib/os/hal/src/hal_usb_hid.c file:

Compiling hal_usb_hid.c
./ChibiOS-Contrib/os/hal/src/hal_usb_hid.c:137:3: warning: initialization makes integer from pointer without a cast
   write, read, put, get,
   ^
./ChibiOS-Contrib/os/hal/src/hal_usb_hid.c:137:3: warning: (near initialization for 'vmt.instance_offset')
./ChibiOS-Contrib/os/hal/src/hal_usb_hid.c:137:3: warning: initialization from incompatible pointer type
./ChibiOS-Contrib/os/hal/src/hal_usb_hid.c:137:3: warning: (near initialization for 'vmt.write')
./ChibiOS-Contrib/os/hal/src/hal_usb_hid.c:137:3: warning: initialization from incompatible pointer type
./ChibiOS-Contrib/os/hal/src/hal_usb_hid.c:137:3: warning: (near initialization for 'vmt.read')
./ChibiOS-Contrib/os/hal/src/hal_usb_hid.c:137:3: warning: initialization from incompatible pointer type
./ChibiOS-Contrib/os/hal/src/hal_usb_hid.c:137:3: warning: (near initialization for 'vmt.put')
./ChibiOS-Contrib/os/hal/src/hal_usb_hid.c:138:3: warning: initialization from incompatible pointer type
   putt, gett, writet, readt,
   ^
./ChibiOS-Contrib/os/hal/src/hal_usb_hid.c:138:3: warning: (near initialization for 'vmt.get')
./ChibiOS-Contrib/os/hal/src/hal_usb_hid.c:138:3: warning: initialization from incompatible pointer type
./ChibiOS-Contrib/os/hal/src/hal_usb_hid.c:138:3: warning: (near initialization for 'vmt.putt')
./ChibiOS-Contrib/os/hal/src/hal_usb_hid.c:138:3: warning: initialization from incompatible pointer type
./ChibiOS-Contrib/os/hal/src/hal_usb_hid.c:138:3: warning: (near initialization for 'vmt.gett')
./ChibiOS-Contrib/os/hal/src/hal_usb_hid.c:138:3: warning: initialization from incompatible pointer type
./ChibiOS-Contrib/os/hal/src/hal_usb_hid.c:138:3: warning: (near initialization for 'vmt.writet')
./ChibiOS-Contrib/os/hal/src/hal_usb_hid.c:140:1: warning: initialization from incompatible pointer type
 };
 ^
./ChibiOS-Contrib/os/hal/src/hal_usb_hid.c:140:1: warning: (near initialization for 'vmt.readt')
./ChibiOS-Contrib/os/hal/src/hal_usb_hid.c:140:1: warning: missing initializer for field 'ctl' of 'const struct USBHIDDriverVMT' [-Wmissing-field-initializers]
In file included from ./ChibiOS/os/hal/include/hal.h:119:0,
                 from ./ChibiOS-Contrib/os/hal/src/hal_usb_hid.c:25:
./ChibiOS/os/hal/include/hal_channels.h:64:11: note: 'ctl' declared here
   msg_t (*ctl)(void *instance, unsigned int operation, void *arg);
           ^
./ChibiOS/os/hal/include/hal_channels.h:248:3: note: in expansion of macro '_base_channel_methods'
   _base_channel_methods                                                     \
   ^
./ChibiOS-Contrib/os/hal/include/hal_usb_hid.h:511:3: note: in expansion of macro '_base_asynchronous_channel_methods'
   _base_asynchronous_channel_methods                                        \
   ^
./ChibiOS-Contrib/os/hal/include/hal_usb_hid.h:521:3: note: in expansion of macro '_usb_hid_driver_methods'
   _usb_hid_driver_methods
   ^

Are these warnings normal? Can be fixed in some way?

Thanks in advance!

Please fix:
ChibiOS version - 17.6.3
community/os/hal/include/hal_qei.h

 */
 typedef enum {
   QEI_OVERFLOW_WRAP    = 0,     /**< Counter value will wrap around.        */
-#if QEI_USE_OVERFLOW_DISCARD == TRUE
+#if defined(QEI_USE_OVERFLOW_DISCARD) && QEI_USE_OVERFLOW_DISCARD == TRUE
   QEI_OVERFLOW_DISCARD = 1,     /**< Counter doesn't change.                */
 #endif
-#if QEI_USE_OVERFLOW_MINMAX == TRUE
+#if defined(QEI_USE_OVERFLOW_MINMAX) && QEI_USE_OVERFLOW_MINMAX == TRUE
   QEI_OVERFLOW_MINMAX  = 2,     /**< Counter will be updated upto min or max.*/
 #endif
 } qeioverflow_t;

I'm using the onewire driver on an STM32F042F6P6 with ARM-GCC 4.9.3. I was having issues with onewireReset always returning false.

The initial check that the bus was high was always failing, even though it was definitely high (verified with multimeter) and there was no bus activity. If I tried to check the state myself with palReadPad, it would always return 1.

It appears that is somehow related to the uint_fast8_t return type on ow_read_bit. Replacing this line:

if (PAL_LOW == ow_read_bit(owp))

With this:

if ((uint_fast8_t)PAL_LOW == ow_read_bit(owp))

Seems to fix the issue (although it still happens in numerous other places in the code). I have no idea why.

Hello,

I am using the HAL FSMC driver for SDRAM on STM32F746 without any issues. I assume that STM32F4 and STM32F7 share the same FMC hardware. For making it compile, I had to add some switches to the source files.

Normally, there is this statement here to allow compilation only for certain processors:

#if (defined(STM32F427xx) || defined(STM32F437xx) || \
     defined(STM32F429xx) || defined(STM32F439xx))

Please change that to something like this or similar:

#if (defined(STM32F427xx) || defined(STM32F437xx) || \
     defined(STM32F429xx) || defined(STM32F439xx) || \
     defined(STM32F746xx))

for use with STM32F7 family processors. I am not sure which processors of the F7 family can be used, as I can test only the STM32F746.

This affects the following files:
/os/hal/ports/STM32/LLD/FSMCv1/hal_fsmc.h
/os/hal/ports/STM32/LLD/FSMCv1/hal_fsmc.c
/os/hal/ports/STM32/LLD/FSMCv1/hal_fsmc_sdram.h
/os/hal/ports/STM32/LLD/FSMCv1/hal_fsmc_sdram.c

Thank you,
Adrian

is this possible?
id really like to use this mcu with ChibiOS

Currently when compiling for qmk it will not compile unless you uncomment this line.

Is this a bug or am I missing something? I have mentioned it in qmk/qmk_firmware#21621.

Hello,

Do you plan to add some testhal project for USB HID communication (i.e. for stm32)? Maybe a simple python program for PC side would be also very useful.

Related to #235.
I would like these numbered in straight forward way. What does the design guide say?
@fpoussin @alexclewontin

NUC123_I2C1_GLOBAL_HANDLER → NUC123_I2C0_HANDLER ?
NUC123_I2C1_GLOBAL_NUMBER → NUC123_I2C0_NUMBER ?

NUC123_I2C2_GLOBAL_HANDLER → NUC123_I2C1_HANDLER ?
NUC123_I2C2_GLOBAL_NUMBER → NUC123_I2C1_NUMBER ?

NUC123_HAS_I2C0
NUC123_HAS_I2C1

NUC123_I2C_USE_I2C0
NUC123_I2C_USE_I2C1

I2CD1 → I2CD0 ?
I2CD2 → I2CD1 ?

edit: and why _GLOBAL_ ?

This caused by the fact that the STM32 DMAs data count register is only 16 bits wide.
Therefore the DMA can only handle max. 65535 bytes per transfer.
To be able to handle bigger data sets the CRC low level driver has to split calculations for data sets bigger than 0xFFFF.

Please see attached my suggestion to solve this issue.

0001-Fix-STM32-LLD-CRCv1-large-data-bug-in-DMA-mode.zip

Thanks for the tool, I picked it up as a part of the ChibiOS distribution then found the original on GitHub.

In the case of using STM32F7XX.ioc file

Opening stm32f7_2.ioc
MCU is STM32F765N(G-I)Hx
Opened C:\Program Files\STMicroelectronics\STM32Cube\STM32CubeMX\db\mcu\
Opening GPIO file C:\Program Files\STMicroelectronics\STM32Cube\STM32CubeMX\db\mcu\\IP\GPIO-STM32F76x_gpio_v1_0_Modes.xml
Opening project file stm32f7_2.ioc
Traceback (most recent call last):
  File "mx2board2.py", line 332, in <module>
    defines = gen_defines(proj)
  File "mx2board2.py", line 273, in gen_defines
    ch_num = int(signal[-1:])
ValueError: invalid literal for int() with base 10: 'R'

The error is caused by the fact that the .ioc file contains lines like

SH.S_TIM2_CH1_ETR.0=TIM2_CH1,Input_Capture1_from_TI1

The regular expression at line 271 matches the pattern terminating ETR rather than a digit.
`
defines['PORT'+label] = 'GPIO' + port_key
defines['PAD_'+label] = pad_key

        if re.search(r"TIM\d_CH\d$", signal, re.M):  <---- 
            timer = signal.replace('S_TIM', '').replace('_CH', '')[:-1]
            ch_num = int(signal[-1:])

`
There needs to be a '$' to only match complete strings at the end of the regular expression, this avoids matching names like TIM2_CH1_ETR.
I am not sure whatever other sideffects there are of this change, it produced a valid-appearing board.h after changing this.

I am planning to implement a driver of MAX3421E for ChibiOS. After doing some research, I think the best way to do it is to implement a complex driver that sits on top of the SPI driver. I would try to avoid writing a LLD driver for it since the LLD looks more like a place for "MCU-specific" code and the MAX3421E does not depend on the MCU. However, I also found that the USBH driver calls usbh_lld_* function of specific LLD implementation of a certain MCU, which means the external controller and the MCU built-in controller cannot possibly co-exist if I implement the usbh_lld_* in my driver (and also the code may look weird since usbh_lld_* appears in a complex driver).

So my question: Whatt is the best way to implement such driver that cooperates with USBH, or is it just a bad idea for the current USBH implementation?

When I build my qmk project，I encountered the problem as follows.

Compiling: platforms/chibios/wait.c
platforms/chibios/wait.c: In function 'wait_us':
platforms/chibios/wait.c:24:54: error: excess elements in struct initializer [-Werror]
24 | static const GPTConfig gpt_cfg = {1000000, NULL, 0, 0}; /* 1MHz timer, no callback /
| ^
platforms/chibios/wait.c:24:54: note: (near initialization for 'gpt_cfg')
platforms/chibios/wait.c:24:57: error: excess elements in struct initializer [-Werror]
24 | static const GPTConfig gpt_cfg = {1000000, NULL, 0, 0}; / 1MHz timer, no callback */
| ^
platforms/chibios/wait.c:24:57: note: (near initialization for 'gpt_cfg')
cc1: all warnings being treated as errors
[ERRORS]

Comparing the source hal_gpt_lld.h of HT32 with the one of STM32，the two elements cr2 and dier should be added to the struct GPTConfig.

The source hal_gpt_lld.h of HT32 is in the folder -- "chibios-contrib\os\hal\ports\HT32\LLD\TIMv1".

Hey,

I'm trying to migrate some code for USB Host on MSD connected to OTG2. This with a STM32F7.
This was working just fine in version 19.1.x (if I'm not mistaken).

I can see that a lot of code changes were made in recent versions. Also that the test code that exists is using OTG1.
Any pointers you can give me or "obvious places" to look at, so I can try to pin point the root cause?

Thanks!

The current version of SDRAM drivers breaks execution when calling sdramStart() because of nested calls to osalSysLock(). After sdram_lld_start() -> sdram_lld_init_sequence(), the thread is put to sleep with osalThreadSleepMilliseconds(), which also contains a osalSysLock() statement, leading to the SV4 panic.

I suggest to remove the lock statements from sdramStart() to restore functionality. Are they actually required? If not, I can create a pull request.

Compiling with ChibiOS master and ChibiOS-Contrib master

/home/sdalu/ChibiOS/ChibiOS/os/common/startup/ARMCMx/compilers/GCC/rules.mk:216: target 'build/obj/chcoreasm_v6m.S' doesn't match the target pattern
Compiling
arm-none-eabi-gcc: warning: '-x assembler-with-cpp' after last input file has no effect
arm-none-eabi-gcc: fatal error: no input files
compilation terminated.
/home/sdalu/ChibiOS/ChibiOS/os/common/startup/ARMCMx/compilers/GCC/rules.mk:221: recipe for target 'build/obj/chcoreasm_v6m.S' failed

It should be os/hal/ports/NUMICRO/NUC123/platform.mk
instead of os/hal/ports/NUMICRO/NUC123SD4AN0/platform.mk .
and so on.

It would be great to have i2c support. I was looking into adding the AN32181B for qmk but it is connected via i2c which currently is not supported.

@fishman I don't have any code to open a PR for your reported intermittent detection failure yet, so we can use this issue for discussion.

I still cannot reproduce it. When you experience this failure, how much traffic is being routed through the hub? Is the keyboard the only device, or are there others? When the keyboard failure occurs, do other devices passing through the hub continue to function normally?

Update: my USB hub appears to be on the fritz. I don't think I can reproduce (I've never had the USB hub detected but not the keyboard. I've tested the USB hub with some other devices, and I think the issue is an intermittent connection in the cable. It was cheap and you get what you pay for ¯\_(ツ)_/¯), but I have a new hub on the way, which should be helpful in diagnosis.

To enable qmk/qmk_firmware#17477

Datasheet: CH579M.pdf

Add branches for ChibiOS 19.1.x and 20.3.x

The current master seems to work with 19.1.x, and the commit messages indicate that too, but it would be much clearer to with the proper branch name.

For 20.3.x some changes to the makefiles and config files must be made. Apart from that at least the USB_MSD driver seems to work.

Hi, i need a help of ChibiOS's Contrib community.

I am newbie in ChibiOS architectory. So faced with promblem when adopting COMPv1 to stm32L031 (M0).

In stm32l031 (Mo) Comparator uses interrupt - ADC1_COMP_IRQHandler same that a ADC.

But in COMPv1 - STM32_COMP_1_2_3_IRQ_PRIORITY (COMP_1) and and STM32_COMP_1_2_3_IRQ_PRIORITY (COMP_2).

As i understand ChibiOS HAL use ADC1_COMP_IRQHandler for ADC HAL Driver? Or i can change library to use ADC1_COMP_IRQHandler?

I see that you've recently updated the STM32 libraries to include the new STm32F413xx, but there isn't a ChibiOS port yet to utilize it.

Hello,

I'm porting ChibiOS to the Teensy 3.5 board and while it's nowhere near production quality, I'm at a point that the GPIOs and all the 4 UARTs work correctly. Also all the standard tests run successfully.

However I'm stuck with a problem relevant to the PLL configuration: every information I need to generate the PLL divisor and multiplier is known at compile time, yet I'm still computing their value at runtime on the MCU, similar to the way it's done in the K20x ports.

I could simplify everything by running a custom program on the host system that includes the needed headers and generates a header with the PLL divisor and multiplier. The latter would then be included directly by hal_lld.c which would correctly set the PLL. In the case no suitable combination of divisor and multiplier is found the tool would return an error and end the compilation.

My problem is I don't know the ChibiOS makefiles very well, so I added custom targets in my board.mk. Unfortunately I had to hardcode the gcc compiler, options, include paths and everything. I had to provide a fake first: all target to keep the existing make behaviour.

Is there a better way to do it? Should I stick to the way explained above?
Or should I compute the values for the PLL at runtime?

Thank you.