npmx drivers

[WesC]

I am using a STM32 with the NPMX drivers.

I am having a few issues and wanted to see if there are recommendations.

Issue 1:

disabling the interrupts does not seem to work

	// Clear all events before enabling interrupts, just in case other interrupt source was configured before.
	for (uint32_t i = 0; i < NPMX_EVENT_GROUP_COUNT; i++) {
	        npmx_err = npmx_core_event_interrupt_disable(&npm1300_instance, (npmx_event_group_t)i, NPMX_EVENT_GROUP_ALL_EVENTS_MASK);
	        if(npmx_err == NPMX_SUCCESS)
	        {
	        		printf("Event Cleared\n");
	        		osDelay(100);
	        }

the above code comes from the PORTING Guide.

when i run that block it looks like it never reaches the NPMX_SUCCESS

I have attached the I2C transactions

it looks like it is writing 0x00 and not 0xFF as I would expect.

Issue 2:

I am trying to set a GPIO as an Interrupt.

	npmx_error_t ret;
	npmx_gpio_t *npmx_gpio_struct;

	// Set GPIO 3 as GPIO Interrupt.
	//
	npmx_gpio_struct = npmx_gpio_get(&npm1300_instance, 3);

	ret = npmx_gpio_mode_set(&npmx_gpio_struct, NPMX_GPIO_MODE_OUTPUT_IRQ);

when i run this it does not look like I get the Index of 3 and I cannot tell about the pointer to the I2C Instance

then the call to npmx_gpio_mode_set throws a hard Fault.

I have tried it with declaring a separate npmx_gpio_t structure and inline declaration like the porting guide.  They both throw faults.

which I guess I should ask if the init function call from the porting guide

static npmx_error_t my_i2c_write_function(void * p_context, uint32_t register_address, uint8_t * p_data, size_t num_of_bytes);
static npmx_error_t my_i2c_read_function(void * p_context, uint32_t register_address, uint8_t * p_data, size_t num_of_bytes);


static void my_npmx_initialization_function(void)
{
    npm1300_backend.p_read = my_i2c_read_function;
    npm1300_backend.p_write = my_i2c_write_function;
    npm1300_backend.p_context = NULL; // Optional context for our use

    npmx_error_t npmx_err = npmx_core_init(&npm1300_instance, &npm1300_backend, NULL, true);
    // TODO: Verify that npmx_err == NPMX_SUCCESS
}

should give me a I2C like this

it appears to write 0x05 and 0x09, then read 0x00.

is this expected from the init Function?

I am looking more into it, but any guidance can help

[SergeiOv]

I would first of all like to see your `my_i2c_write_function` and `my_i2c_write_function` implementations, are you sure they are implemented properly?

On the first screenshot nothing is happening really. It's neither a write nor a read transaction. Examples of those you can see in the datasheet https://docs.nordicsemi.com/bundle/ps_npm1300/page/chapters/core_components/ctrl_reg/doc/frontpage.html#d89e68

On the second screenshot it seems to read out the 0x0509 register (ADC_CONFIG) getting value 0. While this can be part of the initialization function, it shouldn't be the only transaction in this case... Did you check the return code of this function call?

[WesC]

I am having trouble with the correct STM32 HAL I2C calls for TX and RX.  I believe I have the TX working correctly because I call to clear all interrupts and it appears to work.  the RX might still be an issue.  in the npmx_core_inti() function it looks like it needs to read several registers if you set "Restore Values" to True.  but i only get one read for the ADCCONFIG, but nothing else.  how many reads of registers should there be?
adc, ntc, charge, discharge, ship.

Is there any more guidance on the preferred function calls to write to registers? do you

need to call npmx_xxx_get() for any specific function before calling npmx_xxx_set()?

[SergeiOv]

There is no point in using any of the npmx functions as long as the I2C read/write functions are not properly implemented. If you struggle with the implementation, I could give some guidance based on your current code, or at least a reference to STM32 documentation I should use to implement this.

> but i only get one read for the ADCCONFIG, but nothing else.

I suspect that the I2C read function returns an error which makes it the first and the last read as the init function will terminate on any communication error. That's why I asked you to check the init return code.

[WesC]

i have the I2C working now.  so my only issue is how to use the npmx drivers correctly.

it turns out I needed to do a conversion from the STM HAL I2C error return status to the npmx_error_t enumeration. so i was returning the correct enum in the I2C read write functions.

I believe I am starting to understand the nPMX drivers.  

for example, would this be the correct way to enable vbat to auto measure every second in single measurement mode:

// Enable VBAT auto measure every 1 second in single measurement mode
    npmx_adc_config_t adc_conf;
    adc_conf.vbat_burst =0;									//Set ADCCONFIG VBAT BURST to SINGLEMODE
    adc_conf.vbat_auto = 1;									//set ADCONFIG VBAT AUTO to Trigger measurement every 1 Second
    npmx_adc_t * adc = npmx_adc_get(&npm1300_instance, 0);
    ret =  npmx_adc_config_set(adc, &adc_conf);

I have many questions about just the basic order of configuring things and use of correct masks for enabling/disabling charger, creating callbacks correctly, ....

I guess I will keep trying and open a ticket if I run into issues.

thanks for your help

[SergeiOv]

Good to hear you've solved the I2C issues. Yes, using npmx drivers is not very straight-forward as it allows much finer tuning of different parameters, etc. But that's the appeal of the bare-metal flavour of drivers for many, for simplicity you could use our Zephyr native drivers.

To help you get through the learning curve on npmx if you continue this way, we have built docs, e.g. here's the page on ADC since you're trying to get some measurements now: https://nordicsemiconductor.github.io/npmx/drivers/adc/index.html

On the front page of these docs we've also linked https://github.com/NordicSemiconductor/npmx-zephyr where you can find various npmx usage examples. The samples are integrated into the Zephyr environment, but the way the npmx APIs are used does not change based on the environment, so those could be copied (with some adjustments to your use case) if found useful.