From gniibe at fsij.org  Wed Oct  2 03:58:01 2019
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Wed, 02 Oct 2019 10:58:01 +0900
Subject: USB control transfers vs ZLP
In-Reply-To: <alpine.BSO.2.21.1909301444470.25093@resin.csoft.net>
References: <alpine.BSO.2.21.1808142314030.54718@resin.csoft.net>
 <87zhxn82zw.fsf@iwagami.gniibe.org>
 <alpine.BSO.2.21.1808262304190.54718@resin.csoft.net>
 <87va7wqokv.fsf@fsij.org>
 <alpine.BSO.2.21.1909031323160.24493@resin.csoft.net>
 <87o9003ou0.fsf@iwagami.gniibe.org>
 <alpine.BSO.2.21.1909032026230.24493@resin.csoft.net>
 <alpine.BSO.2.21.1909301444470.25093@resin.csoft.net>
Message-ID: <874l0rx61i.fsf@iwagami.gniibe.org>

Jeremy Drake <jeremy at drastrom.science> wrote:
> I localized the breakage to commit 5d344ac, as that version does not work
> when adding the <= fix, and 06eef36 does.

Which version of GCC are you using?

I'm using gcc-arm-none-eabi in Debian (15:7-2018-q2-6), and no troubles.
-- 


From gniibe at fsij.org  Thu Oct  3 09:29:47 2019
From: gniibe at fsij.org (NIIBE Yutaka)
Date: Thu, 03 Oct 2019 16:29:47 +0900
Subject: USB control transfers vs ZLP
In-Reply-To: <alpine.BSO.2.21.1910012217290.25093@resin.csoft.net>
References: <alpine.BSO.2.21.1808142314030.54718@resin.csoft.net>
 <87zhxn82zw.fsf@iwagami.gniibe.org>
 <alpine.BSO.2.21.1808262304190.54718@resin.csoft.net>
 <87va7wqokv.fsf@fsij.org>
 <alpine.BSO.2.21.1909031323160.24493@resin.csoft.net>
 <87o9003ou0.fsf@iwagami.gniibe.org>
 <alpine.BSO.2.21.1909032026230.24493@resin.csoft.net>
 <alpine.BSO.2.21.1909301444470.25093@resin.csoft.net>
 <874l0rx61i.fsf@iwagami.gniibe.org>
 <alpine.BSO.2.21.1910012147471.25093@resin.csoft.net>
 <alpine.BSO.2.21.1910012217290.25093@resin.csoft.net>
Message-ID: <87h84qqob8.fsf@iwagami.gniibe.org>

Jeremy Drake <jeremy at drastrom.science> writes:
> Another interesting difference with this one is that I am using a DFU
> bootloader.  Hasn't been an issue up to now, and don't see how the commit
> that seemed to break things would matter.  One thing I did notice is that
> if the board was "soft" reset by the DFU bootloader after it had used the
> USB to receive a new build, it would work with the newer chopstx, but
> would then fail on a cold reset from unplugging and replugging not in DFU
> mode.

For this issue (invocation from DFU bootloader), the commit

    0de43691ab8e9456ec2b476cd85ab18a749ffb89

matters, probably, I guess.

Does your board has a gate or a transistor to control D+ line?

For the commit (and related commits), I tried to clean up things around
USB initialization.

Before the commit, asserting the gate is controlled by usb_lld_sys_init
and usb_lld_sys_shutdown routines.

Now, usb_lld_sys_init and usb_lld_sys_shutdown are not called anymore by
USB driver, and it assumes that your board configuration of
VAL_GPIO_LED_ODR has correct value.
-- 


From gniibe at fsij.org  Mon Oct  7 09:09:36 2019
From: gniibe at fsij.org (Niibe Yutaka)
Date: Mon, 07 Oct 2019 16:09:36 +0900
Subject: USB control transfers vs ZLP
In-Reply-To: <alpine.BSO.2.21.1910041502350.25093@resin.csoft.net>
References: <alpine.BSO.2.21.1808142314030.54718@resin.csoft.net>
 <87zhxn82zw.fsf@iwagami.gniibe.org>
 <alpine.BSO.2.21.1808262304190.54718@resin.csoft.net>
 <87va7wqokv.fsf@fsij.org>
 <alpine.BSO.2.21.1909031323160.24493@resin.csoft.net>
 <87o9003ou0.fsf@iwagami.gniibe.org>
 <alpine.BSO.2.21.1909032026230.24493@resin.csoft.net>
 <alpine.BSO.2.21.1909301444470.25093@resin.csoft.net>
 <alpine.BSO.2.21.1910041430260.25093@resin.csoft.net>
 <alpine.BSO.2.21.1910041502350.25093@resin.csoft.net>
Message-ID: <87r23pm3pr.fsf@jumper.gniibe.org>

Jeremy Drake wrote:
> Confirmed this fix works with both versions of GCC I've tested with.
>
> diff --git a/mcu/usb-st-common.c b/mcu/usb-st-common.c
> index b97df38..58fe4fc 100644
> --- a/mcu/usb-st-common.c
> +++ b/mcu/usb-st-common.c
> @@ -235,10 +235,9 @@ usb_lld_init (struct usb_dev *dev, uint8_t feature)
>    USB->CNTR = CNTR_FRES;
>    USB->CNTR = 0;
>
> -  USB->BTABLE = 0;
> -
>    /* Clear Interrupt Status Register, and enable interrupt for USB */
>    USB->ISTR = 0;
> +  USB->BTABLE = 0;
>    USB->CNTR = (CNTR_CTRM | CNTR_OVRM | CNTR_ERRM
>                | CNTR_WKUPM | CNTR_SUSPM | CNTR_RESETM);
>  }

Thanks a lot.  I applied your patch and pushed it.
-- 


From ardavast at noiseoverip.com  Fri Oct 25 22:44:11 2019
From: ardavast at noiseoverip.com (Ardavast Dayleryan)
Date: Fri, 25 Oct 2019 23:44:11 +0300
Subject: Acknowledgement button on Olimex STM32-H103
Message-ID: <CAG=VjEkYYdAFpBMy_2NZN1Ou0X0NLYbQchyDSfXqmjB-+gUUbw@mail.gmail.com>

Hello,

I'm trying to get the acknowledgement button feature  to work on an Olimex
STM32-H103 board: https://www.olimex.com/Products/ARM/ST/STM32-H103/
The schematic can be found on this link:
https://www.olimex.com/Products/ARM/ST/STM32-H405/resources/STM32-H405_sch.pdf

The schematic shows that the button is connected to PA0 with a 10k
pull-up.  After browsing through the code and the STM32 reference manual
I tried to create the patch listed below.  However it doesn't work - I
can sign files without any problem, but it doesn't wait for
confirmation.  I've never programmed anything on an STM32 before, so I
guess I'm missing something obvious.  Can anyone help me to get on the
right track with this?

diff --git a/board/board-olimex-stm32-h103.h
b/board/board-olimex-stm32-h103.h
index 348860d..05f9b8f 100644
--- a/board/board-olimex-stm32-h103.h
+++ b/board/board-olimex-stm32-h103.h
@@ -12,7 +12,7 @@
 #define GPIO_LED_CLEAR_TO_EMIT          12
 #define GPIO_USB_BASE   GPIOC_BASE
 #define GPIO_USB_CLEAR_TO_ENABLE        11
-#undef  GPIO_OTHER_BASE
+#define GPIO_OTHER_BASE GPIOA_BASE

 /*
  * Port C setup.
@@ -29,5 +29,9 @@
 #define VAL_GPIO_LED_CRL            0x44888888      /*  PC7...PC0 */
 #define VAL_GPIO_LED_CRH            0x88837888      /* PC15...PC8 */

+#define VAL_GPIO_OTHER_ODR          0xFFFFFFFF
+#define VAL_GPIO_OTHER_CRL          0x44444448      /*  PA7...PA0 */
+#define VAL_GPIO_OTHER_CRH          0x44444444      /* PA15...PA8 */
+
 #define RCC_ENR_IOP_EN      RCC_APB2ENR_IOPCEN
 #define RCC_RSTR_IOP_RST    RCC_APB2RSTR_IOPCRST
diff --git a/contrib/ackbtn-stm32f103.c b/contrib/ackbtn-stm32f103.c
index d06a5e2..0f3a448 100644
--- a/contrib/ackbtn-stm32f103.c
+++ b/contrib/ackbtn-stm32f103.c
@@ -65,6 +65,14 @@ ackbtn_init (chopstx_intr_t *intr)
       pin_config |= PINCFG_EDGE_RISING;
       break;

+    case BOARD_ID_OLIMEX_STM32_H103:
+      afio_exticr_index = 0;
+      afio_exticr_extiX_pY = AFIO_EXTICR1_EXTI0_PA;
+      irq_num = EXTI0_IRQ;
+      pin_config = 0x0001;
+      pin_config |= PINCFG_EDGE_RISING;
+      break;
+
     case BOARD_ID_FST_01SZ:
     default:
       /* PA3 is connected to a hall sensor DRV5032FA */
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnuk-users/attachments/20191025/48a250b9/attachment.html>

From gniibe at fsij.org  Mon Oct 28 10:20:08 2019
From: gniibe at fsij.org (Niibe Yutaka)
Date: Mon, 28 Oct 2019 18:20:08 +0900
Subject: Acknowledgement button on Olimex STM32-H103
In-Reply-To: <CAG=VjEkYYdAFpBMy_2NZN1Ou0X0NLYbQchyDSfXqmjB-+gUUbw@mail.gmail.com>
References: <CAG=VjEkYYdAFpBMy_2NZN1Ou0X0NLYbQchyDSfXqmjB-+gUUbw@mail.gmail.com>
Message-ID: <87d0ehjkfr.fsf@jumper.gniibe.org>

Ardavast Dayleryan writes:
> I've never programmed anything on an STM32 before, so I guess I'm
> missing something obvious.  Can anyone help me to get on the right
> track with this?

I think that RCC setting is also needed to update.

> diff --git a/board/board-olimex-stm32-h103.h
> b/board/board-olimex-stm32-h103.h
> index 348860d..05f9b8f 100644
> --- a/board/board-olimex-stm32-h103.h
> +++ b/board/board-olimex-stm32-h103.h
> @@ -12,7 +12,7 @@
>  #define GPIO_LED_CLEAR_TO_EMIT          12
>  #define GPIO_USB_BASE   GPIOC_BASE
>  #define GPIO_USB_CLEAR_TO_ENABLE        11
> -#undef  GPIO_OTHER_BASE
> +#define GPIO_OTHER_BASE GPIOA_BASE
>
>  /*
>   * Port C setup.
> @@ -29,5 +29,9 @@
>  #define VAL_GPIO_LED_CRL            0x44888888      /*  PC7...PC0 */
>  #define VAL_GPIO_LED_CRH            0x88837888      /* PC15...PC8 */
>
> +#define VAL_GPIO_OTHER_ODR          0xFFFFFFFF
> +#define VAL_GPIO_OTHER_CRL          0x44444448      /*  PA7...PA0 */
> +#define VAL_GPIO_OTHER_CRH          0x44444444      /* PA15...PA8 */
> +
>  #define RCC_ENR_IOP_EN      RCC_APB2ENR_IOPCEN
>  #define RCC_RSTR_IOP_RST    RCC_APB2RSTR_IOPCRST

Here.  It should be:

==========================
#define RCC_ENR_IOP_EN     (RCC_APB2ENR_IOPAEN | RCC_APB2ENR_IOPCEN)
#define RCC_RSTR_IOP_RST   (RCC_APB2RSTR_IOPARST | RCC_APB2RSTR_IOPCRST)
==========================

Please try.
-- 


From gniibe at fsij.org  Mon Oct 28 11:32:29 2019
From: gniibe at fsij.org (Niibe Yutaka)
Date: Mon, 28 Oct 2019 19:32:29 +0900
Subject: GD32VF103
Message-ID: <87blu1jh36.fsf@jumper.gniibe.org>

Hello,

I got a board with GD32VF103 (named Longan Nano), which has a 32-bit
RISC-V core and GD's peripherals.  Please note that while GD32F103 is
STM32F103 clone-like with ARM Cortex-M3 core, GD32VF103 comes with RV32
IMAC core.

For technical resources, I found the repo for the chip:

    https://github.com/riscv-mcu/

Looking the manual of GD32VF103, the USB peripheral is not the one of
GD32F103 but it has functionality of USB OTG (both of host and
function).

When it is configured by BOOT0/BOOT1 pins, it can be seen as USB DFU
board.  I accessed it by dfu-util.
--