CCS/MSP430I2040: UART communication lost after every fix interval.

Hi Anuradha,

it is difficult to asses based on the given information, what's going on in your setup. I would recommend debugging the UART link, using this application report, describing how to. Best regards

Peter

Hello Peter,

Thanks for reply.

It is nothing to do with setup as I am testing it without load.

Testing on UART countinuosly by sending request after every 10 secs, it is observation that after every 40 mins it doesn't respond to query. Resumes communication again in 6-7 secs again. Rest of the time communication is fine.

As per my understanding this possible reasons,

1. Wathchdog Timer - I checked, it is OFF.

2. Any other reason controller is resets or going in sleep mode?--how to confirm that? 

3. Interrupt priority -  can interrupt priority affect uart communication?

As I am using EMDC generated code for metering application, I need guidance from you to is there any possibility for such UART behaviour?  

Expecting feedback on metering code, if it closes uart port periodically for some time, please check and revert.

Thanks,

Anuradha.

Hi Anuradha,

2. Any other reason controller is resets or going in sleep mode?--how to confirm that?

I assume you're operating the whole setup with an active debug connection. Thus e.g. setting a breakpoint at the start of your code, would catch the occurrence of a reset, where ever it might be coming from.

Checking whether the device was in a sleep mode. The most simple thing would be not using any sleep mode in your code.

3. Interrupt priority -  can interrupt priority affect uart communication?

It should be pretty easy checking, whether the code is configuring other modules for interrupt activities enabled or not and whether their interrupt priorities are higher than the one from the used UART.

40min seems to me a pretty long time frame, to come from something in the code, but definitely I would try checking whether there is something in the code that runs with a repetition rate of 40min. The question would also be, whether this is accurately 40min, or just a rough number. Please consider also some external influences, like is there some kind of a timeout, or sleep of other connected equipment, like your PC going to standby? Or equipment generating high EMI noise on the power line with a time frame of 40min?

Best regards

Peter

Hello Peter,

I am not testing it in debug mode, it is flashed board testing.

Detail set up description is,

Powered ON  Application board  (mounted MSP 430i2040 controller programmed with EMDC generated metering code modified as per application) connected to external module which is sending request commands on UART after every 10 secs, after receiving request Application board sends answer to that query by defined protocol.

As we are using it for lighting application, but for uart fault finding reason we have not connected any load to it. Just monitoring communication.

Also PC is not sending command or not connected to this Application board physically  (so no possibility stand by causes this issue.)

Application has dashboard(to monitor server data), on which it displays as Fault when no communication. And it is occurring after every 40-43 mins.

Also we monitored Rx Tx lines on Oscilloscope  for fault event , Rx has request command but on Tx no pulses. 

I am using only APIs of this code and not aware detail background execution, so need guidance. 

Thanks,

Anuradha.

Hello,

It sounds like there's an issue with your communication state machine stemming from the changes made to the EMDC-generated code.

The default EMDC application code is designed to report the values every 1 second to the host (emulated by the EMDC GUI). If there are no zero crossings detected, then it'll report every 2 seconds. This can be adjusted in the 'hal_adc.c' file. By default, there's not a query commend that the host sends to the EMDC target requesting the results. You've probably modified the communication state machine in 'hmi.c' to support this.

if(gEmSWResult.phaseMetrologyPing[EM_PH_A_IDX]->cycleCount == gEmSWConfig.algorithmConfig->mainNomFreq)
{
	phaseDataReady |= HAL_ADC_PHASE_A_DATA_READY;
	EM_perDataChunk(&gEmSWConfig, (EM_SW_Lib_Result_Handle *) &gEmSWResult, EM_PH_A_IDX);
}
else if (gEmSWResult.phaseMetrologyPing[EM_PH_A_IDX]->sampleCount > (2*EM_SAMPLING_FREQ_HZ))
{
	phaseDataReady |= HAL_ADC_PHASE_A_DATA_READY;
	EM_perDataChunk(&gEmSWConfig, (EM_SW_Lib_Result_Handle *) &gEmSWResult, EM_PH_A_IDX);

Also, to learn more about the foreground and background processes, please refer to the EMDC application flowchart found here. We just released EMDC v1.40 which you can find here. You can learn more about what's been updated here.

Regards,

James

Hello James,

Yes I have edited State Machine in hmi.c

As I don't want to have communication with HMI so I removed all state machine and kept only below code,

void HMI_stateMachine(uint8_t resultStatus)
{
HMI_sendPhaseResults(gCommandHandler.calibPhaseIdx, gCommandHandler.calibPhaseID);

}

This I was implemented for testing and receiving proper data at UART. Just issue on reply on UART after every 41-43 hrs. How can I resolve it?

Please find attached modified code for review.

Thanks,Metering_New_Protocol2_CurrentA (2).zip

Anuradha.

Hello Anuradha,

Thanks for sharing your project. I see that you've edited more than just 'hmi.c'. I would highly recommend breaking your code development up into smaller more manageable sections rather than adding everything at once. For example, changing the baud rate to 9600 in the EMDC-generated code is a good first step. The original code uses a much higher baud rate of 250k baud to get the data out to the host between ADC samples. I would not add the timer and other code until the communication is working correctly at 9600 baud.

Now, looking at the while(1) loop in your 'main.c', I see that you're doing a lot every iteration. In the original code, we send the results over UART only when they are ready. In the while(1) loop, you call EMLibGUIApp_Engine() which checks if the foreground process is ready (that's good) but then your HMI_stateMachine() function doesn't check if the results are ready and seems to send results every time. Combined with everything else in your while(1) loop, you may be overrunning the communication.

Also, I didn't see where commands are received from the host and processed. For EMDC, we add a 1 ms delay between commands, so the target has enough time to process the commands while doing everything else. Please keep this in mind for your implementation.

Regards,

James

Hello James,

Thanks for reviewing code.

First of all, my query resolved as there was modification required in requesting protocol. And I was suspecting metering code as I edited it a lot.

Yes, I did it by the same way you suggested, I implemented change one by one, firstly checked for 9600 baud rate only for communication and then step by step for getting metering parameters on uart in required protocol format. Till now it is working smooth.

Now we are at integration phase with third party so facing some new issues, it was one of that but now it is resolved.

I just wanted to confirm from metering code side if there are any chances to have this issue because of any background activity or because I missed anything while editing this code. But I guess you have reviewed this. Please suggest me required modifications to get better result if any.

Thanks again.

Hello Anuradha,

It sounds like you've made some progress. I don't really have much to add to what I've already shared. The background process is triggered by the ADC ISR and there's a check on the cycle count to update the results every 1 second. I would keep that unchanged if that meets your requirements. Then, when a command is received, you can send out up-to-date results. If you would change the background process to run for 40 minutes (much much much longer than 1 second), variables in the code would most likely overflow causing the results to be inaccurate.

Hope this helps!

Regards,

James