mbed-os-example-client does not work on STM Nucleo F401RE #37
Comments
|
@SeppoTakalo @kjbracey-arm Can you please check this ? |
|
Can we enable some trace? |
|
It seems tracing is not working as expected (ticket here ARMmbed/mbed-os#449) |
|
For which module should I enable tracing? |
|
Simplest thing to do is add mbed-trace.enable to your mbed_app.json, in this section: |
|
Debug output on F401RE: |
|
Did you clean after changing the config? (There's no autodependency on it). I'm expecting trace from the network stack. |
|
I assume so. My commandline was |
|
Somehow I suspect that the nd_tasklet_main does not start. |
|
Seems likely, as you cleaned. It didn't manage to start the stack at all. |
|
Any hint on what could be going wrong? |
|
Got to go now, but perhaps lack of memory for the Nanostack (nsdynmemlib) pool? Insufficent threads configured in RTX (I don't think error returns from thread creation are checked)? |
|
Any hints on what one can tweak and where? |
|
Way back, I recall seeing timing problems with atmel-rf-driver. In order to verify actually what happened, we need to check with RF sniffer if the device is able to send anything at all. There is also assumption on the driver that 'CS' release required specific timeouts, not sure if these are true on every platform. |
|
@SeppoTakalo Previously with mbed3 this was working on an ST board. Are there changes from mbed3 to mbed5 that could break it? @kjbracey-arm Where could I start looking for nsdynmemlib and Insufficent threads? Highly likely that this is the source since the ST board has less RAM. |
|
Seems that the F401RE has When removing it, the example does not fit anymore into ROM. What has increased the ROM so much since mbed3? |
|
ARM Internal Ref: IOTCLT-879 |
|
problem also reported during OOB RC#4 |
|
Should be fixed by #58, needs verify. |
@markus-becker-tridonic-com using newlib which is thread safe versus newlib-nano which isn't. Its about a 20k ROM penalty with GCC |
|
Investigated more. mbedtls is a lot smaller now. Thanks. The ETHERNET build is size-wise fine: The MESH_LOWPAN_ND build is still big: Now with the preparations for the public release, it seems you have put in the binary nanostack, with every option enabled (Thread + 6LoWPAN + BorderRouter?). Is there a possibility to have a Thread Router, 6LoWPAN Router or Border Router nanostack binary and being able to select with e.g. NANOSTACK_BINARY_USER_CONFIG? If not, what is the supported way of putting in the nanostack source with the correct config selectable from the config NANOSTACK_USER_CONFIG_FILE like mbedtls does now with #58? |
|
@sg Thanks for the pointer! Cloning sal-stack-nanostack-private to replace sal-stack-nanostack doesn't work without any tweaking (compilation gives a bunch of errors about type redefinitions, for instance). I'm trying to sort it out but I was wondering: Is there any specific branch/tag that we should use with the current mbed-os release? (so far I've tried master and the v5.0.5 tag) |
|
@MarceloSalazar would you have a look at @javier-moreno-tridonic-com's comment? Do we need to clone all of
Or is just sal-stack-nanostack-private enough? Which tags/versions should work? |
|
@markus-becker-tridonic-com @javier-moreno-tridonic-com I just tried 5.0.5 and everything built smoothly. The version of Nanostack included in mbed-os is 5.0.5. It was checked out from branch 5.0-maint. Can you please have a Skype session session with me ? +-----------------------------+--------+-------+-------+ |
|
Had a Skype session with @javier-moreno-tridonic-com . The problem was the same file names on the include path. Its a known-issue on mbed-os5. |
|
I opened a new issue for better tracking. For completion, the compilation errors can be fixed in windows by replacing the following lines: mbed-osFile Replace #include "Socket.h"With #include "network-socket/Socket.h"atmel-rf-driverFile Replace #include "Mutex.h"
#include "Thread.h"
using namespace rtos;With #include "rtos.h" |
|
New addition to this target issue. Using GCC is running great for us now. Today I tried to use the same code but compiled with armcc. The example crashes with a HardFault in osEventObs->pre_start(); mbed-os/rtos/rtx/TARGET_CORTEX_M/rt_CMSIS.cosStatus osKernelStart (void) {
uint32_t stack[8];
if (__get_IPSR() != 0U) {
return osErrorISR; // Not allowed in ISR
}
/* Call the pre-start event (from unprivileged mode) if the handler exists
* and the kernel is not running. */
/* FIXME osEventObs needs to be readable but not writable from unprivileged
* code. */
if (!osKernelRunning() && osEventObs && osEventObs->pre_start) {
osEventObs->pre_start(); //LINE CAUSING THE CRASH
}
switch (__get_CONTROL() & 0x03U) {
case 0x00U: // Privileged Thread mode & MSP
__set_PSP((uint32_t)(stack + 8)); // Initial PSP
if (os_flags & 1U) {
__set_CONTROL(0x02U); // Set Privileged Thread mode & PSP
} else {
__set_CONTROL(0x03U); // Set Unprivileged Thread mode & PSP
}
__DSB();
__ISB();
break;
case 0x01U: // Unprivileged Thread mode & MSP
return osErrorOS;
case 0x02U: // Privileged Thread mode & PSP
if ((os_flags & 1U) == 0U) { // Unprivileged Thread mode requested
__set_CONTROL(0x03U); // Set Unprivileged Thread mode & PSP
__DSB();
__ISB();
}
break;
case 0x03U: // Unprivileged Thread mode & PSP
if (os_flags & 1U) { return osErrorOS; } // Privileged Thread mode requested
break;
}
return __svcKernelStart();
}Stack trace
|
|
Any updates on this? |
|
@SeppoTakalo @hasnainvirk Any progress on this issue ? |
|
@javier-moreno-tridonic-com which version of armcc are you using ? |
|
This one
|
|
Seemingly 96K RAM is not enough for mbed-os-example-client (with 6LoWPAN-ND) to work well. i) With GCC, RAM gets consumed while mbedTLS starts writing ecp encryption tables in RAM. This is the error code MBEDTLS_ERR_SSL_ALLOC_FAILED -32512 (-0x7F00). But the system does not crash because with GCC there is a sane mechanism of Heap and stack overlap control. Anyway, app does not connect to mDS successfully because right after handshake, while writing some ecp stuff , memory gets exhausted. ii) With armcc, RAM gets consumed just like th eprevious case. But there is no sane mechanism to keep check on heap and stack overlap. And hence you get the Hard fault. An issue for sane handling of heap and stack collision is made on mbed OS ARMmbed/mbed-os#2618. However, we should now look how to reduce RAM consumption ? ROM Tables @SeppoTakalo @kjbracey-arm . Moreover, it seems we are low on ROM too as this platform have 512K of Flash. |
|
@javier-moreno-tridonic-com Our Client Lead suggested a quick fix, https://github.com/ARMmbed/mbed-os-example-client/blob/master/mbedtls_mbed_client_config.h#L108 |
|
Good news, I'll try that ASAP. On the meantime I made a test to check the RAM usage. To do so I tried modifying the startup_stm32f401xe.S to fill the RAM with a pattern. ; Reset handler
Reset_Handler PROC
EXPORT Reset_Handler [WEAK]
IMPORT SystemInit
IMPORT __main
LDR R0, =0x20000000 // lowest RAM position
LDR R1, =0x20018000 // highest RAM position F401
SUBS R1, R0 // RAM size
LDR R2, =0xEFBEADDE // fill pattern (DEADBEEF) in the dump file
FillRam STR R2, [R0]
ADDS R0, R0, #4
SUBS R1, #4
BNE FillRam
LDR R0, =SystemInit
BLX R0
LDR R0, =__main
BX R0
ENDPI dumped RAM contents on crash and used the following script to check how many 4 Bytes are different from this "DEADBEEF" pattern: import argparse
import re
def main():
parser = argparse.ArgumentParser(description='Counts used RAM from a RAM dump as plain text')
parser.add_argument('-f', '--dumpfile', type=str, help='The dump file')
args = parser.parse_args()
dumpfile = open(args.dumpfile, 'rb')
print dumpfile
tokens = re.split(' |\n', dumpfile.read())
usedram = 0
print('Procesing ' + str(len(tokens)) + ' tokens...')
for token in tokens:
if token != 'DEADBEEF' and token != '':
usedram += 4
print('Used RAM: ' + str(usedram) + ' Bytes')
if __name__ == "__main__":
main()This was the result: I looks like on crash time there should be ~30KB free, assuming the startup file from armcc does the same as the one for gcc and fills with zeros the statically allocated variables. If that is not the case and the memory is not zeroed, it might be that the heap for the nanostack is taking those 30KB. Please keep in mind that is the first time that I fiddle with this kind of assembler so there could be errors, I'd be happy if somebody could review this carefully |
|
@javier-moreno-tridonic-com It seems that the hard fault issue because of RAM exhaustion with ARMCC is fixed in mbed-o-5.1.3 |
|
@javier-moreno-tridonic-com can you close this as the original issue has been solved now. Thank you |
|
@TuomoHautamaki Well today I tried again a clean checkout of the example using mbed-os 5.1.3 and the fix proposed by @hasnainvirk to save 8KB of RAM but the example still crashes with a HardFault. on the same line. If you mean that @markus-becker-tridonic-com initial problem is fixed I can close this issue and open a new one about the HardFault and reference this one. Is that what you want? |
|
@TuomoHautamaki @markus-becker-tridonic-com I had tested it with mbed-OS 5.1.3 and the memory work arounds. It worked fine for me. I just had a Skype session with @javier-moreno-tridonic-com and I demonstrated him the solution. I suspect the OpenOCD tool that Javier is using causes troubles because it uses JTAG. By design Nucleo F401RE uses PB_4(i.e., D5 in terms of Arduino) for JTAG whereas the firefly radio shield is also using D5 for SPI operation. I would suggest a test without using external tools. Use mbed-cli to build and flash like drag and drop. Do not build with debug-info. |
|
I can finally confirm @hasnainvirk theory. Apparently my debug tools cause some sort of problem that end in a hard fault crash. @markus-becker-tridonic-com can you close this issue??? |
I am trying to get the mbed-os-example-client to run on an STM Nucleo F401RE with the 6LoWPAN shield and the configuration.
In order to do so, I modified
and
so that it actually fits into ROM.
On the K64:
mbed compile -c -t GCC_ARM -m K64F -j 4
On the F401RE:
mbed compile -c -t GCC_ARM -m NUCLEO_F401RE
The text was updated successfully, but these errors were encountered: