2019-05-06 08:25 AM
I am trying to implement a working MESH network without the participation of a smartphone. The idea is to send messages from all test nodes to one specific node through the MESH, which has the same hardware structure as the rest. This node should process the incoming message and perform some actions with its peripherals. Is it possible? Please advise how best to implement it.
Which profile is better to choose for the model on-off? Please, advise what I should pay attention to.
2019-05-17 07:52 AM
Hi Winfred!
Thanks for your help.
At the moment I have no problems with the compilation and linking of my project in Keil IDE.
Best regards,
Andrey
2019-05-20 12:48 PM
Hi Winfred and alok!
Unfortunately, I'v got some problems with the module.
I suppose that the reason for the error pointed to by Keil. May be with this trouble debugger stops in "UART_Handler(void) {}"
Is there some solution with your opinion?
Best regards,
Andrey
2019-05-20 08:40 PM
It shall be fine.
The Keil error says that the string "Bad BD_MAC_ADDR!\r\n" is not a valid token for the "##" preprocessor, which shall not matter here.
But in case it is really concerned, i think it might be OK to modify the marcros in mesh_cfg_usr.h (line 63):
#define TraceC0(...)
#define TraceC1(...) do { printf( __VA_ARGS__);} while(0)
#define TraceCX(flags, ...) TraceC##flags( __VA_ARGS__)
#define TRACE_I(flag, ...) TraceCX(flag, __VA_ARGS__)
2019-05-21 07:55 AM
Hi Winfred!
You were right. Although the changes made led to the elimination of the preprocessor error, the problem remained. It consists in the fact that the "printf" function displays only four characters. After that, the program hangs in this function and no longer goes. TRACE_I behaves similarly.
Unfortunately, I can’t find a place where the “printf�? output is redirected to UART. Since uKeil does not find a place to redefine the flow from the stdout to the Uart.
Best regards,
Andrey
2019-05-21 08:19 PM
Hi Andrey,
The system was interrupted by another event.
Please try to debug with an ST-Link, back trace the call stack to figure out the "place".
Best Regards,
Winfred
2019-05-22 09:08 AM
Hi, Winfred!
Thanks for the answer. I received the correct response from the PCB using the debugger.
However, there are some features.
The fact is that I managed to get the correct response only in the uKeil debugger mode. I do it like this.
I launch the debugger for execution before the second printf command. Then I press the stop button in the debugger.
Then I put the cursor on the position of the working cycle
/* Main infinite loop */ and again start debugging.
And only after this, I get the correct response from the PCB which can be seen in the picture.
If I just reset the PCB, the board does not work and does not output anything to the UART.
Accordingly, I do not see the activity of the board in the application on the smartphone. Please help solve this problem.
Best regards,
Andrey
2019-05-22 10:47 PM
Hi Andrey,
Please try in Debug Session press 'F5' to run for a while, then break MCU.
Possibly it is in some exception handler. Then you'll be able to backtrace the stack and check how it occurred.
Best Regards,
Winfred
2019-05-23 10:03 AM
Hi Winfred!
Thanks for the answer in my topic. Hope you are well.
I found that the reason for the incorrect work of the program was the discrepancy between the assignment of pins for the UART and the PWM. Sorry for my hasty questions in the past.
I hope that further problems will not arise.
Best regsrds,
Andrey
2019-05-27 07:26 PM
Hi Andrey,
Good to know it works.
The debugger did provide clues:
when the issue occurred, it looped when checking UART TXFF (TX FIFO full) flag.
It means something wrong with the hardware (in your case, GPIO mode configuration) so that BlueNRG-2 was not able to transmit to UART.
static void SdkEvalUart_Send_Data(uint8_t tx_data)
{
/* Wait if TX fifo is full. */
while (UART_GetFlagStatus(UART_FLAG_TXFF) == SET);
/* send the data */
UART_SendData(tx_data);
}/* end SdkEvalUart_Send_Data() */
Best Regards,
Winfred