Hi Giovanni,
friendly ping on this bug/issue.
Cheers,
Stefan
Search found 16 matches
- Thu May 08, 2025 10:26 am
- Forum: Bug Reports
- Topic: STM32G0B1 Single bank flash support
- Replies: 3
- Views: 42804
- Sat Mar 15, 2025 1:25 pm
- Forum: Bug Reports
- Topic: STM32G0B1 Single bank flash support
- Replies: 3
- Views: 42804
STM32G0B1 Single bank flash support
Hi Giovanni,
the g0b1 series feature 128kb flash and a single bank flash memory organisation[1], which is currently missing in the registry and elf driver. I have attached a patch that adds the support. I'm not sure if you're happy with the registry #if defined switch but it is a start .
Cheers ...
the g0b1 series feature 128kb flash and a single bank flash memory organisation[1], which is currently missing in the registry and elf driver. I have attached a patch that adds the support. I'm not sure if you're happy with the registry #if defined switch but it is a start .
Cheers ...
- Sun Dec 15, 2024 1:12 pm
- Forum: Bug Reports
- Topic: STM32 OTGv1 Suspend and Resume Fixes
- Replies: 8
- Views: 24860
Re: STM32 OTGv1 Suspend and Resume Fixes
Hi Giovanni,
looks good now and tested successfully. Thank you.
Stefan
looks good now and tested successfully. Thank you.
Stefan
- Mon Dec 09, 2024 7:02 pm
- Forum: Bug Reports
- Topic: STM32 OTGv1 Suspend and Resume Fixes
- Replies: 8
- Views: 24860
Re: STM32 OTGv1 Suspend and Resume Fixes
Hi Giovanni,
thanks for applying the patch. It is almost correct - what is missing from the patch is the case when a bus resume is detected by looking at the SOF IRQs. This happens after issuing a host remote wakeup by the device itself. The peripheral won't generate a GINTSTS_WKUPINT in this case ...
thanks for applying the patch. It is almost correct - what is missing from the patch is the case when a bus resume is detected by looking at the SOF IRQs. This happens after issuing a host remote wakeup by the device itself. The peripheral won't generate a GINTSTS_WKUPINT in this case ...
- Mon Oct 14, 2024 9:37 am
- Forum: Bug Reports
- Topic: STM32 OTGv1 Suspend and Resume Fixes
- Replies: 8
- Views: 24860
Re: STM32 OTGv1 Suspend and Resume Fixes
Hi Giovanni,
the first patch can be tested by simply suspending the device from the remote host. I did my tests with QMK Firmware but it should be sufficient to use a demo application that uses the USB peripheral e.g. RT tests over CDC and suspend the device by putting the host into sleep and ...
the first patch can be tested by simply suspending the device from the remote host. I did my tests with QMK Firmware but it should be sufficient to use a demo application that uses the USB peripheral e.g. RT tests over CDC and suspend the device by putting the host into sleep and ...
- Mon Sep 09, 2024 8:59 pm
- Forum: Development and Feedback
- Topic: Further Raspberry Pi RP2xxx development on pico-sdk
- Replies: 2
- Views: 26273
Re: Further Raspberry Pi RP2xxx development on pico-sdk
Hi Giovanni,
thanks for your quick reply. I'll try to address your concerns:
1) Naming of types conflicting with OSAL and chibios in general, see semaphore_t but there are others.
For a collision test[1] I included all headers from the mentioned "Hardware Structs Library" and "Hardware ...
thanks for your quick reply. I'll try to address your concerns:
1) Naming of types conflicting with OSAL and chibios in general, see semaphore_t but there are others.
For a collision test[1] I included all headers from the mentioned "Hardware Structs Library" and "Hardware ...
- Sun Sep 08, 2024 6:36 pm
- Forum: Development and Feedback
- Topic: Further Raspberry Pi RP2xxx development on pico-sdk
- Replies: 2
- Views: 26273
Further Raspberry Pi RP2xxx development on pico-sdk
Hi Giovanni,
instead of posting to Discord I rather post here as this seems better suited for longer posts.
To get to the point: I advocate baseing further development stronger on the offical pico-sdk's "Hardware Structs Library" and "Hardware Registers Library" instead on the offical or our own ...
instead of posting to Discord I rather post here as this seems better suited for longer posts.
To get to the point: I advocate baseing further development stronger on the offical pico-sdk's "Hardware Structs Library" and "Hardware Registers Library" instead on the offical or our own ...
- Tue Sep 03, 2024 1:25 pm
- Forum: Bug Reports
- Topic: STM32 OTGv1 Suspend and Resume Fixes
- Replies: 8
- Views: 24860
Re: STM32 OTGv1 Suspend and Resume Fixes
2. Problem
If the application disables the OTG clocks in low power mode in order to save some power, these clocks have to be enabled again if they want to wake the host - otherwise nothing happens:
diff --git a/os/hal/ports/STM32/LLD/OTGv1/hal_usb_lld.h b/os/hal/ports/STM32/LLD/OTGv1/hal_usb ...
If the application disables the OTG clocks in low power mode in order to save some power, these clocks have to be enabled again if they want to wake the host - otherwise nothing happens:
diff --git a/os/hal/ports/STM32/LLD/OTGv1/hal_usb_lld.h b/os/hal/ports/STM32/LLD/OTGv1/hal_usb ...
- Tue Sep 03, 2024 1:21 pm
- Forum: Bug Reports
- Topic: STM32 OTGv1 Suspend and Resume Fixes
- Replies: 8
- Views: 24860
STM32 OTGv1 Suspend and Resume Fixes
Hi Giovanni,
I have another patch for the resume and suspend handling in the OTGv1 driver.
1. Problem:
After resuming from suspend, either by being woken by the host or by waking the host, the already setup'ed in and out endpoints remain disabled. The cause is that otg_disable_ep is called on the ...
I have another patch for the resume and suspend handling in the OTGv1 driver.
1. Problem:
After resuming from suspend, either by being woken by the host or by waking the host, the already setup'ed in and out endpoints remain disabled. The cause is that otg_disable_ep is called on the ...
- Wed Feb 02, 2022 11:36 am
- Forum: User Projects
- Topic: Chibios OS RISC-V GD32VF103 Port and USB OTG lockup problem
- Replies: 17
- Views: 63944
Re: Chibios OS RISC-V GD32VF103 Port and USB OTG lockup problem
Hi Tabulous,
the core problem with the USB lockups with this port weren't related to the USB driver code but to the handling of IRQ tail-chaining in the context switching. I hooked up Seggers SystemView to ChibiOS (bindings are in the contrib repo) and found the problem by noticing that pattern ...
the core problem with the USB lockups with this port weren't related to the USB driver code but to the handling of IRQ tail-chaining in the context switching. I hooked up Seggers SystemView to ChibiOS (bindings are in the contrib repo) and found the problem by noticing that pattern ...