Hi Team,
We are using DA14531MOd and are trying to build a device that should capture the sensor data and send over BLE un-directed. The application uses an accelerometer and pressure sensor. The main application flow is like this:
1. On user_app_init(), initialize accelerometer and enable wakeup controller callback using 'wkupct_register_callback(accel_sensor_interrupt_cb)' and 'wkupct_enable_irq()'.2. Once it calls accel_sensor_interrupt_cb(), initialize the pressure sensor and enable pressure_sensorr_callback for this using another GPIO pin using 'wkupct_enable_irq()'.3. In the pressure_sensorr_callback function read pressure values, and check whether the accelerometer INT pin is still active or not using GPIO_GetPinStatus(). If yes, enable pressure sensor interrupt using 'wkupct_enable_irq()'. This might happen repeatedly as the accelerometer has movement for a long time say 30 seconds.4. After the accelerometer come to a stable state, analyzes the data, and sends the result over BLE. Until then do not advertise any data over BLE. 5. Once BLE advertisement completes, put the device into extended sleep mode and wait for the accelerometer to interrupt again by calling 'wkupct_enable_irq()'.
The accelerometer and pressure sensor is working fine and able to trigger accel_sensor_interrupt_cb() and initialize the pressure sensor. However, the pressure sensor interrupt is not triggering sometimes. Sometimes it works for 3 or 4 interrupts and stops after that, it never calls call back. At this stage, I need to reset the device to work again. On the logic analyzer, I could see that the pressure sensor generated the interrupt as expected but no callback was called in DA14531.
I looked into the samples like 'ble_pressure_sensor_bmp388', 'accel-Sensor'. However, they are reading sensor values for a shorter time.
I thought, there may be some issue in sleep mode and disabled extended sleep mode by using ARCH_SLEEP_OFF. However, when the sleep mode is off, after getting the accelerometer interrupted and starts reading pressure sensor values, after a couple of seconds, the processor is entering into HardFault. I reset the watchdog in the pressure sensor callback however it did not help. I have looked into getting the statement using registres to know the method that caused HardFault, however, it did not help to identify the cause/source of the HardFault call. Anyway I do not want to disable sleep mode so did not spend more time on it and I need a solution with ARCH_EXT_SLEEP_ON mode.
Please advise what would be the best way to achieve this kind of long reading process instead of BLE advertising, but advertise only after the complete reading is done.
Please let me know if you need any further information.
Thank you.
Hi Harish,Thank you for the reply. I am not sure why you are not able to post replies, I will contact internally someone to check on this.
Harish said:I have designed custom board as well with SWCLK and…
Hi OV_Renesas,
Actually I have not disabled SWD debug mode and and kept the INT pins connected to SWCLK but moved to 1-Wire programming instead of using SWDIO and SWCLK for programming. With this change…
Hi Harish,Thank you for posting your question online. From my understanding, you are not triggering the wake-up controller manually, but when the sensors are ready to send data, they will trigger their INT pin which will trigger the wake-up controller. Are you using the same wake-up controller for both sensors? Are you sure that inside your work flow you are configuring the wake up controller multiple times for different reasons (for accel sensor and pressure sensor)? For DA14531 the SDK6 provides two wake up controller interrupts. You are working with wkupct_enable_irq and wkupct_register_callback functions. You can use these functions for the accelerometer sensor and the wkupct2_enable_irq and wkupct_register_callback functions for the pressure sensor. This way you can handle both sensor callback functions. Keep in mind that both of them have the same Priority. You will have to modify the wkupct_quade.c file if you want one sensor to have higher priority than the other. In the user_app_init custom callback function you can declare both wake up controllers with their respective sensor callback functions and enable Extended Sleep Mode.When the accelerometer INT pin has been triggered, the wake-up controller (1) will be triggered, and you will go on the accel_sensor_interrupt_cb function. Inside that function you should disable the Extended Sleep mode, initialize the Accelerometer Sensor and initialize the Communication interface you are using (I2C, SPI, UART etc). Then you will be able to get the accelerometer values. When you have read the measurements you were interested in, you should re-initialize the wake-up controller (1) and enter Extended Sleep Mode. The same logic applies for the pressure sensor as well but for the wake-up controller (2). You stated:
Harish said:On the logic analyzer, I could see that the pressure sensor generated the interrupt as expected but no callback was called in DA14531.
This sounds like the wake-up controller was not properly initialized and set. Could you provide the implementation for the wake-up controller?You also stated:
Harish said: In the pressure_sensorr_callback function read pressure values, and check whether the accelerometer INT pin is still active or not using GPIO_GetPinStatus(). If yes, enable pressure sensor interrupt using 'wkupct_enable_irq()'. This might happen repeatedly as the accelerometer has movement for a long time say 30 seconds.
Could you kindly give more information regarding step 3?First you start getting the Accelerometer measurements and you initialize the Pressure Sensor, when the Pressure Sensor INT pin is triggered, you stop reading the Accelerometer values and you start reading pressure values. If the accelerometer INT pin is still high, are you going to go back to the accelerometer values or continue reading the pressure values? You should decide, which sensor should have the higher interrupt, so in case that both INT pins are triggered, your application will know which sensor to handle first. When you have read both sensors, you should de-activate/put them into sleep mode and have Extended Sleep Mode enabled. After that you should be able to start advertising, connect with your central and send the sensor measurements over a characteristic. Kind Regards,OV_Renesas
Any feed back on my reply to your questions? When I posted it said the replies will be moderated but did not saw it posted here. And just now with this reply I observed that it was showing here immediately. Can you please confirm you received my reply and is still in moderation, otherwise I will reply again.
Hi Harish,Thank you for the reply and the feedback.
Harish said:This is surprising, as I am setting ARCH_EXT_SLEEP_ON as default mode and in user_app_init() I could call accel_sensor_init() which is interacting with sensor over I2C and is working fine as I could see I2C data in Logic Analyser and also Accel sensor is giving INT as per my initialization.
accel_sensor_init()
Are you working with one of our Development Kits or with a custom board?If it is one of our Development Kits, could you use the SmartSnippets Toolbox with the Power Profiler tool in order to monitor the current consumption of the device? Are you able to see the device going into Extended Sleep Mode? The Extended Sleep Mode could be halted until all the Peripherals was shutdown. That is why you should initialize the I2C communication each time you want to access the sensors, and release the I2C when you are not using it. Another explanation would be that you are in Extended Sleep Mode, you are trying to receive the data but you are receiving wrong data. I do not think this is the case since you are able to see the data being transferred though the logic analyzer on the I2C lines.
Harish said:Just an update, I am still facing the issue of not calling pressure_sensor_range_complete_cb() by wkupct1 after some time, once more observation I did after enabling wdg_freeze() and wdg_resume() was, as soon as I stop debugging session, accel INT is working fine, but pressure_sensor_range_complete_cb() never called, not even once.
While you have the debugger attached you will not be able to enter to any sleep mode. If you want to monitor the device while in sleep mode you should use the arch_printf function to print messages into a terminal so you can have an understanding of what functions have been executed.Could you also please clarify which GPIOs have you used for the Accel sensor INT pin and the Pressure sensor INT pin?
Harish said:As you mentioned my sleep modes are not working or some thing related to it, but could not figure out what I missed. As a next immediate step, from my side I will change code to use two separate wake-up controllers for accel INT and pressure sensor INT. However, shall I do any changes or any suggestions?
Thank you for following our recommendations. Try to make sure that you are handling the Wake-Up controller and the app_easy_timers correctly. So there is not a chance that a timer is still running if it is not supposed to and that you initialize each timer and the wake-up controller each time you want to use it. Keep also in mind that the app_easy_timer is from the BLE core so it has a Priority of 1 and the Wake-up controller sets a Priority of 2. So if they occur on the same time, the app_easy_timer will be executed first.Kind Regards,OV_Renesas
After entering all the data and replies, when I posted replies it showed like this and the reply was not showing here. Last time also the same problem. Not sure how to get rid of this. Please suggest shall I type all the replies again or you already got the replies and you can do moderate and post here.
Any suggestions?
Hi Harish,Apologies for the delay.I have not received any reply and unfortunately, I could not find any post from you in the Moderation Queue to approve. Could you please share your replies again?I am sorry for any inconvenience.Kind Regards,OV_Renesas
Oh, it happened again. I do not know how to handle this, may be I will post smaller chunks. Every time I am composing and replying, it is saying it went for moderation but not reaching your team. Let me compose again and do reply with smaller chunks.
Sorry for the inconvenience.
Thanks,
Harish
Today I have tried again and same it said "All replies are moderated....". Hmm.
As it did not posted and gave "Moderation" warning, posting without any format. I am sorry for that until the issue on this forum is solved, I have to this way I guess.
OV_Renesas said:Are you working with one of our Development Kits or with a custom board?
I am using Module Development Kit Pro version(DA14531MOD-00DEVKT-P) with DA14531MOD Daughter Board.
I have designed custom board as well with SWCLK and SWDIO pins as programming, However I am trying all the scenarios first with DevKit and later burning onto custom board. That is when I observed the pressure INT was never triggered even though it works for some time on DevKit.
OV_Renesas said:could you use the SmartSnippets Toolbox with the Power Profiler tool in order to monitor the current consumption of the device?
Sure, I will check with it.
OV_Renesas said:The Extended Sleep Mode could be halted until all the Peripherals was shutdown. That is why you should initialize the I2C communication each time you want to access the sensors,I am initializing all the peripherals in : app_resume_system_from_sleep()
OV_Renesas said:While you have the debugger attached you will not be able to enter to any sleep mode. If you want to monitor the device while in sleep mode you should use the arch_printf function to print messages into a terminal so you can have an understanding of what functions have been executed.Yes, that is why I am already using arch_printf() and observing all the method calls. I have attached the console log output for reference.
OV_Renesas said:Could you also please clarify which GPIOs have you used for the Accel sensor INT pin and the Pressure sensor INT pin? I am using GPIO pins following way:
SCL: P0_8
SDA: P0_7
LED: P0_9
ACCEL_INT: P0_11
PRESSURE_POWER_EN: P0_5
PRESSURE_INT: P0_2/SWCLK
UART2_TX: P0_6
OV_Renesas said:Keep also in mind that the app_easy_timer is from the BLE core so it has a Priority of 1 and the Wake-up controller sets a Priority of 2. So if they occur on the same time, the app_easy_timer will be executed first.Sure, thank you for caution note. I am not using both at a time, so I hope this will not give trouble for me.
I did some more investigation and found something and update on it:
Looks like the issue is with using SWDIO and SWCLK for my INT signals. As they are assigned as SWD pins and not GPIO pins they are not detecting INT signals from my sensor. I have moved the INT connection of my sensor from SWCLK(P0_2) to P0_9 it could generate Wake-Up interrupt. However, I am loosing SWD functionality to burn the code. And I am trying to use 1-Wire programming but facing problems on that as well and having conversation over another thread (programing-custom-board-using-1-wire-with-devkit-pro). Unless that is resolved and disabling SWD DEBUG mode and using SWDIO and SWCLK as GPIO I cannot confirm that the actual problem is solved as I am not sure whether even after disabling SWD functionality whether SWDIO and SWCLK works as general GPIO and will generate Wake-up interrupt or not. So, once the other issue is solved I will try this and will update you. Thanks for your support and giving pointers to the solution.
Thanks & Kind Regards
Harish.
Harish said:I have designed custom board as well with SWCLK and SWDIO pins as programming, However I am trying all the scenarios first with DevKit and later burning onto custom board. That is when I observed the pressure INT was never triggered even though it works for some time on DevKit.
I would guess that the issue is the configuration of the SWCLK and SWDIO pins on your project. These pins are by default for the SWD interface and you will have to disable the debugger before reconfiguring them as GPIO for your project code. Please refer here as how this can be done: https://lpccs-docs.renesas.com/DA14531_FAQs/Software.html#can-i-remap-swd-pins-to-gpios
Harish said:I am initializing all the peripherals in : app_resume_system_from_sleep()
You will not have to initialize all the peripherals every time you wake-up manually. This is performed in the periph_init function (user_periph_setup.c file) every time you wake-up. You should use the app_resume_system_from_sleep custom callback function when you only want to initialize specific peripherals only or when you want to perform a specific action in your project.
Harish said:I am using GPIO pins following way: SCL: P0_8 SDA: P0_7 LED: P0_9 ACCEL_INT: P0_11 PRESSURE_POWER_EN: P0_5 PRESSURE_INT: P0_2/SWCLK UART2_TX: P0_6
I am using GPIO pins following way:
As mentioned before, I believe the issue for not being able to detect the interrupt source is the configuration of the P0_11 and P0_2 pins which are being used by default for the SWD interface. I would personally change the Pressure EN pin to P0_6 and the UART2_TX to P0_5. This way you should be able to perform 1-Wire UART programming whenever you want.
Please try to disable the debugger from P0_11 and P0_2 before configuring them as GPIO, and change the P0_5 from the Pressure sensor EN pin and try to perform 1-Wire UART programming into your Dev Kit and custom board and share any feedback. I believe you should be able to see the interrupt callbacks being triggered correctly after that. Kind Regards,OV_Renesas
Thank you for following up internally regarding replies moderation. It really helps.
And thanks a lot for the detailed explanation and the suggestion on interchanging P0_5 and P0_6. I guess this is the cause of the issue where I was not able to program after my custom code was bur. Thank you once again for helping with it and confirming this. Once my programming issue is solved I will burn with new port assignments and will inform you here. From your explanation and what I observed, I feel it will work.
Thanks and Kind Regards,
Actually I have not disabled SWD debug mode and and kept the INT pins connected to SWCLK but moved to 1-Wire programming instead of using SWDIO and SWCLK for programming. With this change the functionality is working fine, means Wake-up controller is able to generate the INTs with SWCLK.
So, after moving to 1-Wire programming as I am able to use SWCLK and SWDIO and Wake-up controller able to call callbacks when INT happens. Hence we can close this conversation.
Thank you for your guidelines and support on resolving this issue, I appreciate your effort.