These are chat archives for marvell-iot/aws_starter_sdk

27th
Nov 2015
xuehua
@xuehua
Nov 27 2015 00:19
Followed the link at https://github.com/marvell-iot/aws_starter_sdk/wiki/Flashing%20the%20Starter%20Kit to re-program the starter kit with the aws_starter demo. After it is done, it does not work any more. Any ideas?
xuehua
@xuehua
Nov 27 2015 00:32
The step I did is below.C:\WorkSpace\Proj\marvell-aws\aws_starter_sdk>wmsdk\tools\OpenOCD\flash.py -f aw
s_starter_sdk-2015_11_04.blob
Resetting flash to factory settings
Using OpenOCD interface file ftdi.cfg
Open On-Chip Debugger 0.9.0 (2015-05-19-12:09)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
flash
adapter speed: 3000 kHz
adapter_nsrst_delay: 100
Info : auto-selecting first available session transport "jtag". To override use
'transport select <transport>'.
jtag_ntrst_delay: 100
cortex_m reset_config sysresetreq
sh_load
Info : clock speed 3000 kHz
Info : JTAG tap: wmcore.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba
00, ver: 0x4)
Info : wmcore.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : JTAG tap: wmcore.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba
00, ver: 0x4)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x00007f14 msp: 0x20001000
auto erase enabled
Info : Found flash device 'win w25q32fv' ID 0x001640ef
wrote 1376256 bytes from file C:/WorkSpace/Proj/marvell-aws/awsstarter_sdk/aws
starter_sdk-2015_11_04.blob in 17.882000s (75.159 KiB/s)
shutdown command invoked
Resetting flash to factory settings done...
xuehua
@xuehua
Nov 27 2015 00:43
It seems wifi is not turned on any more. The yellow led indicating wifi connection is off now. This is strange. Would any one of you have any idea on the behavior?
BTW, I connected to the serial port and noticed the following prints. Build Time: Nov 4 2015 14:24:25

AWS STARTER DEMO

Anuj Deshpande
@anujdeshpande
Nov 27 2015 05:20
@xuehua Did you press the reset button after flashing the new firmware ?
xuehua
@xuehua
Nov 27 2015 06:25
@anujdeshpande , Yes, after flashing the new firmware, every time I press the reset button, I see the message of Build Time: Nov 4 2015 14:24:25

AWS STARTER DEMO

Rahul Masurkar
@rahulgm
Nov 27 2015 07:50
@kealan Try the following steps to find the point of hard fault :
  1. Load your program using arm-none-eabi-gdb as mentioned before.
  1. Reproduce the hard fault.
  2. After this, in gdb console, use the following custom command:
    (gdb) hf_restore
  3. For your information, this command is defined in wmsdk/tools/OpenOCD/gdbcommands.
    This command will restore the cpu context to the instruction that caused the hard fault. Note that, sometimes the cause of hard fault is propagated across threads (e.g. passing a pointer), so you may have to examine all thread contexts to determine the exact point of origin. You can refer to gdb documentation on how to traverse all threads.
Kealan McCusker
@kealan
Nov 27 2015 09:24
@rahulgm Thanks for getting back to me. When I do that this is the output;
^C
Program received signal SIGINT, Interrupt.
0x00107144 in critical_error ()
(gdb) hf_restore
No symbol "uint16_t" in current context.
Rahul Masurkar
@rahulgm
Nov 27 2015 10:04
@kealan I think I have understood your problem. The stack size you are setting in linker file is used for interrupt context, not for the main thread. Main thread in which main() executes has approx half KB stack. So essentially, you will have to spawn a new thread of the required stack size (8K) and execute your processing.
In current case, stack overflow has happened, corrupting heap and hence hf_restore could not show the back-trace or any useful information.
Kealan McCusker
@kealan
Nov 27 2015 10:48
@rahulgm Thanks that must be it. So in the linker file I set the main stack size which is just used for the ISRs. I see I need to call os_thread_create and set the stack size.
Kealan McCusker
@kealan
Nov 27 2015 13:12
Hi Just a quick question is the ARM Cortex-M4F being clocked at 140 MHz