- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Solved! Go to Solution.
- Labels:
-
ispn:39620:1:0
-
l1:314:1:0
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Rakshith M B
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Rakshith M B
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Rakshith M B
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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