MKE04 Write of PTB3 PDDR Mask Bit causes debugger error

[bds]

Hi,  I'm developing a new project with the MKE04Z8VTG4, and am desiring to use PTB3 as both an analog input and GPIO output.  Initially, I want the port to be initialized as an output with a zero level.  When I try to set the bit in the Data Direction register, some sort of fault occurs.  I understand that PTB3 is normally configured as an analog input).

Code is:

GPIOA->PDDR |= (1<<11);

This is basically the first thing that I am doing in main().

It looks like (for example) PTA1 (which is also configured as a default analog input) works just fine when I write to the PDDR.

GPIOA->PDDR |= (1<<1);

When the error occurs, the debugger (I am using a Segger J-Link) errors out with a deadbeee: Failed to execute MI command.

I am using MCUXpresso v11.0.1.

Is this a bug in the MKE04?  I have searched the forums for any indication that this is an issue, but have not seen any results.

Any help is appreciated.

Best,

Brett Swimley

[Alexis_A]

Hi Brett,

To change this pin you need to use the FGPIO register located at 0xf8000000.

In the SDK there's the following functions that can help you set this.

gpio_pin_config_t led_config = {
    kGPIO_DigitalOutput, 1,
};

/* Init board hardware. */
FGPIO_PinInit(kGPIO_PORTB, 3, &led_config);‍‍‍‍‍‍

Best Regards,

Alexis Andalon

[bds]

Thank you, Alexis, for your response.  This, indeed, did seem to work for me.  However, this begs a few more questions:

1) Should I use FGPIO for all of my GPIO accesses on this part?

2) Normal GPIO Accesses worked for PORTA, Pin 1.  Why did this not work for PORTB, Pin 3?

The Reference manual states:

The GPIO registers are also aliased to the IOPORT interface on the Cortex-M0+ from
address 0xF800_0000.

This implies to me that normal GPIO  access should work.

Why then, did the normal GPIO access not work for PORTB, Pin 3?  I would like to understand the difference.

Best,

Brett Swimley

[Alexis_A]

Hi Brett,

This MCU follows a priority system in the pin assignment, so if you have enable a higher priority multiplexing the pin will follow that one, in this case the ADC is enable by default so you will need to disable this pin assignment if you want to use the GPIO function and not the FGPIO.

Best Regards,

Alexis Andalon

[bds]

Hi Alexis,

That doesn't make sense to me, as the functionality of the PTA1 is also an ADC enabled input, and I had no issues using normal GPIO commands with PTA1.

From the Reference Manual:

With your logic, I should run into the same issue with PTA1 as I do with PTB3, yet I do not. I am able to use the normal GPIO commands (rather than FGPIO) with PTA1 and have run into no problems.  

Honestly, I think there is a bug in the chip.

Thanks,

Brett

[Alexis_A]

Hi Brett,

After some tries, this error disapear, could you try again to modify this pin using the GPIO register?

Best Regards,

Alexis Andalon

[bds]

Hello Alexis,

I am a bit sheepish here.  I believe the issue was the use case for the GPIO.  The GPIO is driving a temperature sense/charger enable pin on a battery charger. I use the pin in input mode in conjunction with the ADC to measure the temperature, and drive the pin low as an output to disable the charger.

Circumstances were such that when I was testing with PTA1, I had a battery inserted, and with PTB3, I had no battery in place  It appears when I disable the charger with no battery, the charger momentarily drops the output voltage below the VDD minimum required for the processor.  This does not happen when a battery is inserted.

I will retest with PTB3 AND a battery inserted. If you hear no more from me, this was the root cause of the issue.

Thank you for your help.

Best,

Brett Swimley