Running Hello World with CY8CKIT-062-WiFi-BT using Modus Toolbox

[AnA_4675486]

Hi,

I'm trying to run Hello World example using Modus Toolbox v2.2 on my CY8CKIT-062-WiFi-BTdevkit. I followed these steps:

- Created new application, chose my devkit (CY8CKIT-062-WiFi-BT), and selected Hello World application

- After project was created, opened Device Configurator and selected pin P13.7 as LED_RED and set Drive mode as Strong Drive, Input buffer off.

-Didn't change anything in the system clock settings and left it as default.

- Changed the alias for GPIO pin name to LED_RED through the main.c

- Built the project successfully

- Generated Launch files

- Programmed the devkit using the program launch file

The LED doesn't blink at all. After debugging the code, it turned out gpio initialization for the LED pin is failing. The result variable is populated with value "67240193" after running cyhal_gpio_init.

- At the end, I also tried changing the system clock settings to use the on-board ECO (17.2032MHz) instead of IMO but that also didn't help.

I was hoping Hello World example should be the most straight forward example to start with! Any idea why this is happening and how I can debug it?

Thanks.

[AnA_4675486]

I have an update about this and a follow up question.

I re-did my experiment but this time only opened the Hello World application in new workspace, built it and programmed it to the devkit without touching anything in Device Configurator. Now the example works fine. Can someone please help me understand what exactly am I breaking while configuring the LED GPIO through Device Configurator? How am I supposed to use device configurator then in general if I want to activate a different SCB or different GPIO?

[MotooTanaka]

Hi,

I tried and followed your sample and I found that

    result = cyhal_gpio_init(CYBSP_D8, CYHAL_GPIO_DIR_OUTPUT,

                             CYHAL_GPIO_DRIVE_STRONG, CYBSP_LED_STATE_OFF);

returns the stupid number.

So I debugged this function and found that

in cyhal_gpio.c

=======================

cy_rslt_t cyhal_gpio_init(cyhal_gpio_t pin, cyhal_gpio_direction_t direction, cyhal_gpio_drive_mode_t drive_mode, bool init_val)

{

    /* Mbed creates GPIOs for pins that are dedicated to other peripherals in some cases. */

#ifndef __MBED__

    cyhal_resource_inst_t pinRsc = _cyhal_utils_get_gpio_resource(pin);

    cy_rslt_t status = cyhal_hwmgr_reserve(&pinRsc);

#else

    cy_rslt_t status = CY_RSLT_SUCCESS;

#endif

    if (status == CY_RSLT_SUCCESS)

    {

        uint32_t pdl_drive_mode = _cyhal_gpio_convert_drive_mode(drive_mode, direction);

        Cy_GPIO_Pin_FastInit(CYHAL_GET_PORTADDR(pin), CYHAL_GET_PIN(pin), pdl_drive_mode, init_val, HSIOM_SEL_GPIO);

    }

    return status;

}

=======================

The comment and the implementation about __MBED__ seems to be opposite.

If we are using MBED (__MBED__) it should check if the pin is used for the MBEB purpose,

cyhal_hwmgr_reserve() seems to check if the pin is already defined, and almost all standard pins

on the connectors seems to be defined in cybsp_types.h.

But since we are not using MBED here, it should be defined as

#ifdef __MBED__

instead of

#ifndef __MBED__

So I changed the function as

======================

cy_rslt_t cyhal_gpio_init(cyhal_gpio_t pin, cyhal_gpio_direction_t direction, cyhal_gpio_drive_mode_t drive_mode, bool init_val)

{

    /* Mbed creates GPIOs for pins that are dedicated to other peripherals in some cases. */

//#ifndef __MBED__

#ifdef __MBED__

    cyhal_resource_inst_t pinRsc = _cyhal_utils_get_gpio_resource(pin);

    cy_rslt_t status = cyhal_hwmgr_reserve(&pinRsc);

#else

    cy_rslt_t status = CY_RSLT_SUCCESS;

#endif

    if (status == CY_RSLT_SUCCESS)

    {

        uint32_t pdl_drive_mode = _cyhal_gpio_convert_drive_mode(drive_mode, direction);

        Cy_GPIO_Pin_FastInit(CYHAL_GET_PORTADDR(pin), CYHAL_GET_PIN(pin), pdl_drive_mode, init_val, HSIOM_SEL_GPIO);

    }

    return status;

}

======================

And now I can initialize a GPIO pin (such as P13_0) as GPIO output without error and it seems to be working.

moto

[Rakshith · Accepted solution]

Hi AnA_4675486​,

Adding on to Moto-san's response -

Although HAL and PDL are compatible, you cannot use both the drivers on a single resource. This will result in conflicts. When a HAL init function is called, it checks whether the resource is available. So in your case when the resource is enabled in Device Configurator, it considers that the pin is used/busy and returns failed status when HAL GPIO init is called.

To make it work, you can follow 2 approaches, the PDL approach or the HAL approach. If you want to use PDL, then you need to enable the pin in Device Configurator and use the PDL APIs in your main.c. If you are using HAL, then you should not enable the resource in Device Configurator. You can directly use the HAL GPIO init API providing the necessary pin and the associated configurations. This also ensures that the project is not dependent on Device Configurator.

Please refer to this thread for a detailed description on the differences between PDL and HAL and regarding the 2 approaches mentioned above - Issues starting with ModusToolbox IDE on Mac

Hope this helps,

Thanks and Regards,

Rakshith M B

[MotooTanaka]

Hi,

Reading Rakshith-san's response, I tried following 2 experiments.

And in the both cases,     the call of

            cyhal_gpio_toggle(CYBSP_D8) ;

worked.

(0) For both, I retuned my modification of cyhal_gpio.c

from

#ifdef __MBED__

back to

#ifndef __MBED__

(1) Not use Device Configurator and call cyhal_gpio_init()

(1.1) I deleted the use check and definition of P13[0]

(1.2) I called cyhal_gpio_init

======

    result = cyhal_gpio_init(CYBSP_D8, CYHAL_GPIO_DIR_OUTPUT,

                             CYHAL_GPIO_DRIVE_STRONG, CYBSP_LED_STATE_OFF);

    /* GPIO init failed. Stop program execution */

    if (result != CY_RSLT_SUCCESS)

    {

        CY_ASSERT(0);

    }

======

(2) I defined the pin in Device Configurator and disabled the call of cyhal_gpio_init()

(2.1) Defined the pin in Device Configurator

(2.2) disabled the call of cyhal_gpio_init()

==================

#if 0

    result = cyhal_gpio_init(CYBSP_D8, CYHAL_GPIO_DIR_OUTPUT,

                             CYHAL_GPIO_DRIVE_STRONG, CYBSP_LED_STATE_OFF);

    /* GPIO init failed. Stop program execution */

    if (result != CY_RSLT_SUCCESS)

    {

        CY_ASSERT(0);

    }

#endif

==================

So, As Rakshith-san suggested,

the definition in the Device Configurator and the call of cyhal_tpio_init()

seem to be exclusive, and we need to use only 1 of them.

BTW, I wonder where in the documents we can find this information...

moto

[Rakshith]

Hello Moto-san,

The init functions call the hardware manager reserve API and this is mentioned in the Hardware Manager HAL Documentation and the documentation in the source files. The HAL documentation also provides a code snippet showing how to free a block used by PDL or configurations. However I could not find it explicitly mentioned. I will try to explain the reason for conflict here.

As the thread originally speaks about a GPIO, I will take a GPIO as an example. When a GPIO is enabled in the Device Configurator, the Device Configurator generates the configuration and the initialization code and it also provides a preview of the code that it generates which you can check by clicking on the Code Preview tab. There you will see that initialization code that will be generated for the pin that is enabled and with the PDL init API, it also calls the HAL hardware manager reserve API. This is done so that the HAL, which does not use the Device Configurator, knows about the different resources enabled. Thus the HAL init throws an error thereby avoiding any sporadic behaviour.

The init_cycfg_pins() in the above snapshot is called by cybsp_init() > init_cycfg_all().

Hope this helps,

Thanks and Regards,

Rakshith M B

[MotooTanaka]

Dear Rakshith-san,

Thank you very much for your kind explanation.

Now I think that I have started understanding what's going on.

But for the new comers of MTB, this can be a common trap.

One of my colleagues taught me that there is another discussion quite similar to this one.

PSOC6 CYHAL_UART with DMA support

So I think that it would be nice if there will be some tutorial or introduction

which shows how to use Device Configurator without stepping on this mine.

Meantime, in the last sample, I recovered the definition in cyhal_gpio.c > cyhal_gpio_init()

from

#ifdef __MBED__

back to

#ifndef __MBED__

But from the comment I would suspect that when using MBED, the pin also needs to be tested for duplication,

but currently, when __MBED__ is defined, the test does not seem to be proceeded.

Best Regards,

8-Oct-2020

Motoo Tanaka

[AlanH_86]

I understand the confusion and am sorry about that.

We recommend that you use the HAL for all normal MCU operations.  This will make your project be compatible with all of our current PSoC6s as well as future Cypress/Infineon MCUs.  It is our intent to never every change the HAL interface.

PDL is a register settings based interface.  There almost certainly will be cases where some very specific feature of the chips is not available in the HAL.  In that case... use PDL.   The interesting question is what happens with the configurators - which largely generate PDL.  This question is still unresolved internally.  But we aspire to get as much as possible to HAL to future proof.

Alan

[AnA_4675486]

Thank you all for looking into this issue. Your explanations about exclusive use of HAL and PDL solved my problem as well. But as a general comment following what Moto-san also mentioned, I think it's worth to have a short introductory video about this topic in Modus Toolbox training videos. I personally started with this link (https://www.cypress.com/training/modustoolbox-101-video-tutorial-series ) to start learning about Modus Toolbox and the confusion about Device Configurator started from there. It would be really nice to add a video about this topic under 101 videos so guys like us who's unfamiliar with the platform won't struggle

Thanks again!

[AlanH_86]

You are right about the videos... I have been talking to the guys about getting this done.

Unfortunately I started running Central R*D last week and this is a bit of a "distraction" 🙂

Alan