Bugs in Kwikstik BSP

[Enni]

Hello there,

I'm using MQX 3.8 with a Kwikstik.  

I found a couple of bugs in the board support package:

1) The function init_hardware() in init_hw.c is not called during initialization. I assume it's part of the board/cpu initialization and should be called automatically. Otherwise one gets all kinds of strange behaviour:

- GPIO port clocks are not enabled -> HARD_FAULT when using certain drivers (ADC for example)

-  _time_delay() does not work correctly (delay too long)

- maybe others, which I did not stumble upon

2) _bsp_channel_io_init() in init_gpio.c uses wrong ADC_SOURCE_MODULE parameter. In line 356 (ADC_GET_MODULE(source) == ADC_SOURCE_MODULE(0)) it uses 0, but this should instead be ADC_SOURCE_MODULE(1) to correspond with defines in adc_mk40.h. 

Took me two days to find those bugs, so I'm posting them here so that others can safe that time (and hoping that they get fixed in the next release) :smileywink:

[c0170]

Hi enni,

what IDE are you using? I checked both bugs you mentioned. I was not able to replicate the first one, second one seems to be mistype which is going to be fixed.

Regards,

MartinK

[Enni]

Hi,

I'm using CW 10.2. I was getting a HardFault when playing with the ADC driver. I stepped through the driver functions and noticed that it occured when the driver tries to set ADC function in the corresponding GPIO register. You wrote in some other thread that the reason for HardFault is often a disabled peripheral clock. So I searched the function which initializes the GPIO clocks (init_hardware()), placed a breakpoint inside and found that it does not get called. After calling it somewhere in the BSP initialization, the problem vanished.

Note that it did not occur when running the provided ADC example. Obviously everything is set up for the default ADC pin...I tried to get the kwikstik microphone working (Port A/Pin 7, ADC10 if I remember correctly).

I have a (somewhat related) question though: When using the ADC and halting and then resuming the MCU via the debugger, the ADC does not provide data anymore (read() call returns 0 from there on). I figured it is because some of the peripherals continue to run despite the MCU being halted by the debugger. But I did not manage to reactivate the ADC again after continueing... firing the trigger via ioctl does not work. Is there some other way to resume the ADC? (although, while I'm typing this, I remember that I did not try to close and then re-open the ADC channel).

[Enni]

Any updates on your findings, Martin? 

If not, just do a _time_delay (1000) using the Kwikstik BSP, you won't get 1 s delay (thats another sign that init_hardware() isn't called) ;-) 

Regarding the ADC stopping: Closing and re-opening the ADC channel does not work. Once it stops working, there is no way to re-enable it... And I have the problem that the ADC sometimes just stops working for no reason (not just when halting the MCU via the debugger). There seems to be something seriously wrong with the ADC driver.

[c0170]

Hi enni,

kwikstik  is working properly at my side. Function init_harware is called in the initialization phase and _time_delay sets properly the defined period. How did you measure the time? did you try to  use _time functions in MQX?

Theres is an issue with the ERR flag in Kinetis. The ERR flag (PDB) is set when theere is a trigger fired from PDB but the ADC is not ready to perform the conversion. This happens when the MCU is in the stop mode and the ADC is stopped also while PDB is running. Unfortunatelly, there is not async event to the CPU signalling that the ERR flag is set so actually the CPU does not know anything about this situation.

 The solution is to check the ERR flag synchronously and when set, clear it. Check Reference Manual , PDB section.

Regards,

MartinK

[Enni]

Hi,

I did not measure time directly, but I flashed a logo on the SLCD with 1sec delay and it was at least 2 sec. And there also was the fact that the MCU crashed when accessing the GPIO peripheral and that the breakpoint inside init_hardware did not halt the MCU.

Anyways, due to other bugs in CW10.2 I decided to give IAR a try and there it worked out of the box (seems to be different startup code). So if you can't reproduce it in CW10.2, I have no idea anymore :smileywink:

Thanks for your tip regarding the ADC, I will try that out. 

[c0170]

Hi Enni,

Thanks for sharing your findings. I will take a look at those next week and get back to you what have i found and fixed as well.

Regards,

MartinK