This note is to collect ideas on doing efficient Power Management in Nuttx.
My basis is I am assuming there is a limited, but rechargeable store of coulombs - (LiIon battery or Supercapacitor) and the supply of coulombs to the store is episodic. It may be a solar panel - which has a diurnal cycle interrupted by a weather system. It might be periodic replacement of a battery supply. I use coulombs as it is the essential method for calculating energy available on SuperCapcitors. Typically battery's are quoted in mAHrs which assumes a constant voltage and is slightly easier to understand. The constant voltage is a myth that that needs to be understood for the true battery capacity.
I've used the Nuttx PM system as a starting point. It is an API and has algorithm for entering into the processors sleep/hibernation - which isn't very efficient from the point of view of minimizing coulomb consumption, and specifically doesn't address dynamic clock management. IMHO dynamic clocking is a crucial part of Arm's power management architecture. I've modified the sleep/hibernation algorithm to be more efficient, however the dynamic clock management is a major rethinking.
Some discussions on nuttx list that have taken place, and I put the context for a specific view I'm developing
https://groups.yahoo.com/neo/groups/nuttx/conversations/messages/15347
Greg has identified a "Random Walk" algorithm for what he would like to see in Nuttx (aspirational at the time of writing)
http://www.nuttx.org/doku.php?id=wiki:nxinternal:dynamic-clocking
https://groups.yahoo.com/neo/groups/nuttx/conversations/messages/15345
Kudo's to Greg Nutt for being so dedicated to Nuttx and making it available as an open source repository.
The design I'm investigating uses a Kinetis processor, and there are NXP software tools for stetting up the clocks. In my experience the clock setup is fragile and much can go wrong with it. When something goes wrong in an Arm processor it often stops working, or generates a hard fault - both difficult to debug. Essential to have a working JTAG debugger to step through the code.
The implementation of reducing power useage is very dependent on hardware design and the processors options designed into silicon. So while its possible to define some abstractions to clocking modes, in the end the implementation is going to be in the processor domain, and going to need testing with that specific processor.
Nuttx.org RTOS Branched Workflow program development
Monday, May 8, 2017
Tuesday, January 17, 2017
Using the RTC date/alarm in KinetisK/FRDM-K64
This is (a wip) tutorial on enabling the RTC Alarms on the KinetisK FRDM-K64.
There are a couple of gottchas to look out for when using time related functions
1) is the system clock internal nuttx maintaned counter or syncs with hardware RTC
2) does the internal format use Julian or epoch time.
3) is the RTC format Julian/yymmddss time, or epoch time
The KinetisK has an internal RTC that is 32bits
(The STM32F4 versions have an internal RTC with yyyymmdd mmss)
The internal clock running off the processor xtal, won't be as accurate as the RTC clock.
However I haven't figured out away for checking which is operational from Nuttx cmd line.
I let it run for 12+hrs and then check the accuracy - if its off by a discernible amount then the chances are its running on the internal clock.
The difference between the internal clock and the RTC could provide some strange RTC alarm failures.
To be able to configure the FRDM-K64 (assuming you have a nuttx build environment) set it as per this previous blog configuring-nuttx-to-use-kinetisk-frdm-k64f.
I've developed this already on a private Nuttx build, and I'm submitting it back into Nuttx, using the FRDM-K64 as the basis for the build.
The K64 has one 32bit register and it needs the following enabled for
make menuconfig
date command
Application Configuration -> NSH Library -> Disable Individual commands
[ ] Disable date
NSH_DISABLE_DATE=N
RTC support
System Type--> Kinetis Peripheral Support & [*] RTC
CONFIG_KINETIS_RTC
Device Drivers-> Timer Driver Support-> [*] RTC Driver Support
--- RTC Driver Support
│ │ [*] Date/Time RTC Support
│ │ [*] Hi-Res RTC Support
│ │ (1) Hi-Res RTC frequency (NEW)
│ │ [*] RTC Alarm Support
│ │ (1) Number of alarms (NEW)
│ │ [*] RTC Driver Support
│ │ [*] RTC IOCTLs
│ │ [ ] External RTC Support (NEW)
CONFIG_RTC_DATETIME
CONFIG_RTC_HIRES=y
CONFIG_RTC_FREQUENCY=1
CONFIG_RTC_ALARM=y
CONFIG_RTC_NALARMS=1
CONFIG_RTC_DRIVER=y
CONFIG_RTC_IOCTL=y
To be able to test
Application -> Examples-> RTC alarm driver example
[*] RTC alarm driver example
│ │ (100) Alarm task priority
│ │ (2048) Alarm stack size
│ │ (/dev/rtc0) RTC device path
│ │ (1) Alarm signal
plug in the FRDM-K64 after updates (as described at mbed), on the USB SDA to a host
On the computer connect to the serial port that comes up.
Compile and then take the nuttx.bin and drop it on the USB port
Some background, about the Kinetis K devices and family,
I've put up a number of memory maps
groups.yahoo.com/neo/groups/nuttx/files/KinetisComparision/
The Kinetis K has two generations of chips, and a number of families.
The familes K20, K40 K60, K64 are feature descritption
the generations sometimes have enhancements to the feature descriptions
The K60P 100MHz is a generation1 device with base line RTC features
The K60P 120MHz is a generation2 device with RTC enhanced features.
The K66 is only a generation2 device
Configuring Nuttx to use a KinetisK FRDM-K64 with SDA upload
This is a place holder to describe how to start using the FRDM-K64 package
Briefly I plug FRDM-K64 SDA uUSB is plugged into Windows10.
Then it mounts a disk say E "MBED (E:)" and a com port
I connect a TTY (Tera Term) to the com port at the speed specified in Nuttx serial port.
The Nuttx output is set to binary as follows
make menuconfig
Build Setup-> Binary Output Formats->
[ ] rrload binary format
[*] Intel HEX binary format
[ ] Motorola S-Record binary format
[*] Raw binary format
[ ] U-Boot uImage ----
and then make it.
On completion, pickup the
nuttx.bin
and drop it on the "MBED (E:)" which programs the FRDM-K64.
It still requires the FRDM-K64 reset button to be pressed, but then it responds on the TTY.
Briefly I plug FRDM-K64 SDA uUSB is plugged into Windows10.
Then it mounts a disk say E "MBED (E:)" and a com port
I connect a TTY (Tera Term) to the com port at the speed specified in Nuttx serial port.
The Nuttx output is set to binary as follows
make menuconfig
Build Setup-> Binary Output Formats->
[ ] rrload binary format
[*] Intel HEX binary format
[ ] Motorola S-Record binary format
[*] Raw binary format
[ ] U-Boot uImage ----
and then make it.
On completion, pickup the
nuttx.bin
and drop it on the "MBED (E:)" which programs the FRDM-K64.
It still requires the FRDM-K64 reset button to be pressed, but then it responds on the TTY.
Wednesday, July 13, 2016
USB Host MSC test -hung 'zombie' process
Validating software is the process of trying to get reasonable coverage of the functionality in reasonable situations.
A 2nd test at trying to push the USB Host MSC has produced an interesting result -
A new version of ps also supplies a deeper view of the tasks and how much the stack has been used.
The end result was a series of hung processes - to be poetic a zombie undead process!
My take is that somewhere deep in the system (far deeper than I can go) occasionally the process isn't exiting correctly.
The good news for me is that the USB Host MSC has not failed in a bunch of system failures, zombie processes, Hard Faults, and that is what I need from the system.
Trying to be a good netizen (is that a nutter!) I've raised an issue against it in case anybody else is playing in this area.bitbucket.org/nuttx/nuttx/issues/11/hung-process
'ps' when called uses this as per this update.
https://bitbucket.org/nuttx/apps/commits/dd7c4c94935889fee77d79a188b62f11aa3fb0c6
To enable the stack (and heap) to be monitored with a watermark (the functionality changed about this time - but the Stack Coloration needs to be set now for its usage in ps, whenever its done)
From make menuconfigs
-->Build Setup-->Debug Options
[*] Stack coloration
[*] Heap coloration
Specifically Clicking on "Stack coloration" and then pressing 'h'
" Enable stack coloration to initialize the stack memory to the value
of STACK_COLOR and enable the stack checking APIs that can be used
to monitor the level of stack usage."
So pullin the latest changes, making a new build
$mknx.sh
$stwr
nsh> mount -t vfat /dev/sda /usb0
nsh>
Taking the one test script of the previous blog and using vi (cheat sheet for vi) I did the following
shuntils----
date >> /usb0/t/l_free
date >> /usb0/t/l_date
hello >> /usb0/t/l_free
free >> /usb0/t/l_free
ps >> /usb0/t/l_free
nsh> uname -a
NuttX 17.6 nxd47wk_wkd47tst1_20160713_1444 arm stm32f4discovery
So the ps that failed while the script was running is that it has exceeded the CONFIG_NFILE_DESCRIPTORS allocation of files at that point in time which is 8.
Of course the release investigation is why it isn't cleaning up, which is probably related to not dispatching the process correctly - leaving the zombie process.
include/errno.h: 24 -> EMFILE
fs/vfs/fs_open.c:
191 /* Associate the inode with a file structure */
192
193 fd = files_allocate(inode, oflags, 0, 0);
194 if (fd < 0)
195 {
196 ret = EMFILE;
197 goto errout_with_inode;
198 }
The suggestion from Greg Nuttx was "you need to set CONFIG_NFILE_DESCRIPTORS larger."
However trying builds for 10, 14, 32 resulted in it running for a few seconds then a "Hard Fault Exception" - won't go there. This seems like another Nuttx brittleness.
The good news is that the file system is good and removable for inspection on Win10.
So I'm learning that having two destination files l_date & l_free seems to cause a total increment in pid of 3. Possibly one for the new process "shuntils" and one for each file - but that's a guess.
Rerunning this test with an extra date to verify time taken
/usb0/t/shuntils----
date >> /usb0/t/l_date
hello >> /usb0/t/l_free
date >> /usb0/t/l_free
free >> /usb0/t/l_free
ps >> /usb0/t/l_free
date >> /usb0/t/l_free
sh [32764:100]
sh [32767:100]
sh [7:100]
sh [10:100]
A 2nd test at trying to push the USB Host MSC has produced an interesting result -
A new version of ps also supplies a deeper view of the tasks and how much the stack has been used.
The end result was a series of hung processes - to be poetic a zombie undead process!
My take is that somewhere deep in the system (far deeper than I can go) occasionally the process isn't exiting correctly.
The good news for me is that the USB Host MSC has not failed in a bunch of system failures, zombie processes, Hard Faults, and that is what I need from the system.
Trying to be a good netizen (is that a nutter!) I've raised an issue against it in case anybody else is playing in this area.bitbucket.org/nuttx/nuttx/issues/11/hung-process
'ps' when called uses this as per this update.
https://bitbucket.org/nuttx/apps/commits/dd7c4c94935889fee77d79a188b62f11aa3fb0c6
To enable the stack (and heap) to be monitored with a watermark (the functionality changed about this time - but the Stack Coloration needs to be set now for its usage in ps, whenever its done)
From make menuconfigs
-->Build Setup-->Debug Options
[*] Stack coloration
[*] Heap coloration
Specifically Clicking on "Stack coloration" and then pressing 'h'
" Enable stack coloration to initialize the stack memory to the value
of STACK_COLOR and enable the stack checking APIs that can be used
to monitor the level of stack usage."
So pullin the latest changes, making a new build
$mknx.sh
$stwr
nsh> mount -t vfat /dev/sda /usb0
nsh>
Taking the one test script of the previous blog and using vi (cheat sheet for vi) I did the following
shuntils----
date >> /usb0/t/l_free
date >> /usb0/t/l_date
hello >> /usb0/t/l_free
free >> /usb0/t/l_free
ps >> /usb0/t/l_free
------
shspawn-----
set FSTOP /usb0/t/fstop
until [ -f $FSTOP ]
do
sh /usb0/t/shuntils &
sleep 1
done
--------
nsh> sh /usb0/t/shspawn &
# However after about 15 minutes it had failures. (see later) and seems to have left some zombie processes.
#The pid in this code is a signed integer, and wraps at 16xxxx
nsh>
#however also failed on
nsh> umount usb0
nsh: umount: umount failed: 16 "Device or resource busy"
It turns out this "Device or resource busy" also means files open on /usb0 so I'm guessing is likely to be derived from the hung processes - and while an indicator not the root cause.
It turns out this "Device or resource busy" also means files open on /usb0 so I'm guessing is likely to be derived from the hung processes - and while an indicator not the root cause.
nsh> uname -a
NuttX 17.6 nxd47wk_wkd47tst1_20160713_1444 arm stm32f4discovery
# off its starts testing with some manual 'ps'.
sh [121:100] #new spawn with PID
sh [124:100]
sh [127:100]
ps
PID PRI POLICY TYPE
NPX STATE EVENT SIGMASK
STACK USED FILLED COMMAND
0 0 FIFO
Kthread --- Ready
00000000 0 0
0.0% Idle Task
1 224 FIFO Kthread --- Waiting Signal
00000000 2028 292
14.3% hpwork
2 100 FIFO Task
--- Waiting Semaphore
00000000 1004 508
50.5% usbhost
3 100 FIFO Task
--- Running
00000000 4076 852
20.9% init
4 100 RR pthread --- Waiting Signal
00000000 2044 788
38.5% <pthread> 0x10002f80
nsh> sh [135:100]
sh [138:100]
sh [141:100]
sh [149:100]
sh [152:100]
ps
PID PRI POLICY TYPE
NPX STATE EVENT SIGMASK
STACK USED FILLED COMMAND
0 0 FIFO
Kthread --- Ready
00000000 0 0
0.0% Idle Task
1 224 FIFO Kthread --- Waiting Signal
00000000 2028 292
14.3% hpwork
2 100 FIFO Task
--- Waiting Semaphore
00000000 1004 508
50.5% usbhost
3 100 FIFO Task
--- Running
00000000 4076 852
20.9% init
4 100 RR pthread --- Waiting Signal
00000000 2044 788
38.5% <pthread> 0x10002f80
nsh> sh [155:100]
sh [158:100]
sh [166:100]
ps sh [169:100]
PID PRI POLICY TYPE
NPX STATE EVENT SIGMASK
STACK USED FILLED COMMAND
0 0 FIFO
Kthread --- Ready
00000000 0 0
0.0% Idle Task
1 224 FIFO Kthread --- Waiting Signal
00000000 2028 292
14.3% hpwork
2 100 FIFO Task
--- Waiting Semaphore
00000000 1004 508
50.5% usbhost
3 100 FIFO Task
--- Running 00000000 4076
852 20.9% init
4 100 RR pthread --- Waiting Signal
00000000 2044 788
38.5% <pthread> 0x10002f80
169 100 RR pthread --- Ready 00000000 2044
812 39.7% <pthread> 0x10004420
#NOTE: A spawned file snapshoted while running
nsh> sh [172:100]
sh [175:100]
sh [183:100]
sh [186:100]
# Hey Hey off for lunch while the system works
#start is- Jul 13 14:54:49 2016
#sadly on returning find that it failed again (with more of a log) 20minutes later at Jul 13 15:14:33 2016
# and the log shows ps: open failed: 24 "Too
many open files" from nuttx/include/errno.h:
Jul 13 15:14:32 2016
Hello, World!!
total used free largest
Mem: 188096 31392 156704 120368
PID PRI POLICY TYPE NPX STATE EVENT SIGMASK STACK USED FILLED COMMAND
0 0 FIFO Kthread --- Ready 00000000 0 0 0.0% Idle Task
1 224 FIFO Kthread --- Waiting Signal 00000000 2028 292 14.3% hpwork
2 100 FIFO Task --- Waiting Semaphore 00000000 1004 508 50.5% usbhost
3 100 FIFO Task --- Waiting Semaphore 00000000 4076 852 20.9% init
4 100 RR pthread --- Waiting Signal 00000000 2044 788 38.5% <pthread> 0x10002f80
5065 100 RR pthread --- Running 00000000 2044 1060 51.8% <pthread> 0x10005310
859 100 RR pthread --- Waiting Semaphore 00000000 2044 900 44.0% <pthread> 0x10004420
Jul 13 15:14:33 2016
Hello, World!!
<<<<missing ps>>>>>
Jul 13 15:14:34 2016
Hello, World!!
<<<<<strange ps>>>>
total used free largest
Mem: 188096 36336 151760 120368
PID PRI POLICY TYPE NPX STATE EVENT SIGMASK STACK USED FILLED COMMAND
nsh: ps: open failed: 24 "Too many open files"
0 nsh: ps: open failed: 24
0 0 0.0% nsh: ps: open failed: 24
Jul 13 15:14:35 2016
Hello, World!!
<<<<<strange ps>>>>
total used free largest
Mem: 188096 36336 151760 120368
PID PRI POLICY TYPE NPX STATE EVENT SIGMASK STACK USED FILLED COMMAND
nsh: ps: open failed: 24
0 nsh: ps: open failed: 24
0 0 0.0% nsh: ps: open failed: 24
# so now stop the script from running by
nsh> echo stop > /usb0/t/fstop #pwd is usb/tst1
#Trying 'ps' there are a few strang processes still present, that don't look like they died.
nsh> ps
PID PRI POLICY TYPE
NPX STATE EVENT SIGMASK
STACK USED FILLED COMMAND
0 0 FIFO
Kthread --- Ready
00000000 0 0
0.0% Idle Task
1 224 FIFO Kthread --- Waiting Signal
00000000 2028 292
14.3% hpwork
2 100 FIFO Task
--- Waiting Semaphore
00000000 1004 508
50.5% usbhost
3 100 FIFO Task
--- Running
00000000 4076 972
23.8% init
859 100 RR pthread --- Waiting Semaphore 00000000 2044
900 44.0% <pthread> 0x10004420
5069 100 RR pthread --- Waiting Semaphore 00000000 2044
812 39.7% <pthread> 0x10005310
7614 100 RR pthread --- Waiting Semaphore 00000000 2044
812 39.7% <pthread> 0x10005f80
So the ps that failed while the script was running is that it has exceeded the CONFIG_NFILE_DESCRIPTORS allocation of files at that point in time which is 8.
Of course the release investigation is why it isn't cleaning up, which is probably related to not dispatching the process correctly - leaving the zombie process.
include/errno.h: 24 -> EMFILE
fs/vfs/fs_open.c:
191 /* Associate the inode with a file structure */
192
193 fd = files_allocate(inode, oflags, 0, 0);
194 if (fd < 0)
195 {
196 ret = EMFILE;
197 goto errout_with_inode;
198 }
The suggestion from Greg Nuttx was "you need to set CONFIG_NFILE_DESCRIPTORS larger."
However trying builds for 10, 14, 32 resulted in it running for a few seconds then a "Hard Fault Exception" - won't go there. This seems like another Nuttx brittleness.
The good news is that the file system is good and removable for inspection on Win10.
nsh> ls -ls usb0/tst1
/usb0/tst1:
-rw-rw-rw- 172 shuntil
-rw-rw-rw- 1123855
l_free
-rw-rw-rw- 136 shuntils
-rw-rw-rw- 79 shspawn
-rw-rw-rw- 32823 l_date
-rw-rw-rw- 6 fstop
So I'm learning that having two destination files l_date & l_free seems to cause a total increment in pid of 3. Possibly one for the new process "shuntils" and one for each file - but that's a guess.
Rerunning this test with an extra date to verify time taken
/usb0/t/shuntils----
date >> /usb0/t/l_date
hello >> /usb0/t/l_free
date >> /usb0/t/l_free
free >> /usb0/t/l_free
ps >> /usb0/t/l_free
date >> /usb0/t/l_free
------
/usb0/t/shspawn-----
set FSTOP /usb0/tst1/fstop
until [ -f $FSTOP ]
do
sh /usb0/t//shuntils
&
sleep 1
done
--------
nsh> mount -t vfat /dev/sda /usb0
nsh> sh /usb0/t/shspawn
&
For a 2sec interval - this is a lot slower - I ran it overnight and the pid wrapped at least twice
sh [32764:100]
sh [32767:100]
sh [7:100]
sh [10:100]
For some reason three was one zombie process pid=283, and it happened in the first pid 0-32767
sh [28060:100]
sh [28063:100]
ps
sh [28071:100]
PID PRI POLICY TYPE NPX STATE EVENT SIGMASK STACK USED FILLED COMMAND
0 0 FIFO Kthread --- Ready 00000000 0 0 0.0% Idle Task
1 224 FIFO Kthread --- Waiting Signal 00000000 2028 292 14.3% hpwork
2 100 FIFO Task --- Waiting Semaphore 00000000 1004 508 50.5% usbhost
3 100 FIFO Task --- Running 00000000 4076 868 21.2% init
5 100 RR pthread --- Waiting Signal 00000000 2044 788 38.5% <pthread> 0x10002f80
28071 100 RR pthread --- Ready 00000000 2044 1100 53.8% <pthread> 0x10005330
283 100 RR pthread --- Waiting Semaphore 00000000 2044 812 39.7% <pthread> 0x10004420
nsh> sh [28074:100]
sh [28078:100]
sh [28086:100]
sh [28063:100]
ps
sh [28071:100]
PID PRI POLICY TYPE NPX STATE EVENT SIGMASK STACK USED FILLED COMMAND
0 0 FIFO Kthread --- Ready 00000000 0 0 0.0% Idle Task
1 224 FIFO Kthread --- Waiting Signal 00000000 2028 292 14.3% hpwork
2 100 FIFO Task --- Waiting Semaphore 00000000 1004 508 50.5% usbhost
3 100 FIFO Task --- Running 00000000 4076 868 21.2% init
5 100 RR pthread --- Waiting Signal 00000000 2044 788 38.5% <pthread> 0x10002f80
28071 100 RR pthread --- Ready 00000000 2044 1100 53.8% <pthread> 0x10005330
283 100 RR pthread --- Waiting Semaphore 00000000 2044 812 39.7% <pthread> 0x10004420
nsh> sh [28074:100]
sh [28078:100]
sh [28086:100]
So stopping
echo stop >/usb0/t/fstop
nsh> cd
nsh> umount usb0
nsh: umount: umount failed: 16
# Failed again - probably due to pid=283 - but no way of listing it.
# Checking ps, the stack useage is very pleasing, and the stack sizes could be reduced if needed - but better to have them to large at this stage.
nsh> ps
PID PRI POLICY TYPE NPX STATE EVENT SIGMASK STACK USED FILLED COMMAND
0 0 FIFO Kthread --- Ready 00000000 0 0 0.0% Idle Task
1 224 FIFO Kthread --- Waiting Signal 00000000 2028 292 14.3% hpwork
2 100 FIFO Task --- Waiting Semaphore 00000000 1004 508 50.5% usbhost
3 100 FIFO Task --- Running 00000000 4076 972 23.8% init
283 100 RR pthread --- Waiting Semaphore 00000000 2044 812 39.7% <pthread> 0x10004420
USB Host MSC succesfull test
Tutorial: Creating a test to validate a logging function on the USB Flash drive.
Validate in this context means - create a simple test that seems like it is reasonable exercise of some functionality and then let it run.
Test : Write entries to a log file.
The test script "shuntil"
------------------------------------
set FSTOP /usb0/tst1/fstop
until [ -f $FSTOP ]
do
date >> /usb0/tst1/l_date
free >> /usb0/tst1/l_free
ps >> /usb0/tst1/l_free
sleep 1
done
Validate in this context means - create a simple test that seems like it is reasonable exercise of some functionality and then let it run.
Test : Write entries to a log file.
The test script "shuntil"
------------------------------------
set FSTOP /usb0/tst1/fstop
until [ -f $FSTOP ]
do
date >> /usb0/tst1/l_date
free >> /usb0/tst1/l_free
ps >> /usb0/tst1/l_free
sleep 1
done
------------------------------
is pretty simple. Write three entries to two files every second.
Initially I enabled vi
Application Configuration à
System Libraries and NSH Add-Ons
[*] VI Work-Alike Text Editor ---- CONFIG_SYSTEM_VI
(64) Display width (columns) (NEW)
(16) Display height (rows) (NEW)
(0) Debug level (NEW)
(2048) Builtin
task stack size (NEW)
(100) Builtin
task priority (NEW)
I'm not that proficent in 'vi', I've always had another editor to use. So I spell it out for anybody else taking the plunge. The help is theapps/system/vi/vi.c
mknx.sh
stwr
To start the testing
nsh> uname -a
NuttX 17.6 nxd47wk_wkd47tst1_20160713_1444 arm stm32f4discovery
nsh> mount -t vfat /dev/sda /usb0
nsh> cd /usb0/tst1
# It turns out vi doesn't use pwd - so start it up and then specify the write path at the end
nsh>vi
i #cmd to input - copy the test script in. There is a limit on Rx buffer size so copy/paste half the file and then next half. Mental note need to try xmondem,
#To finish -
<ESC> : w /usb0/tsts1/shunitl<ret>
:q<ret>
>nsh ls -ls # shows file
nsh> sh shutil &
# Thats it test is running. Best leave overnight.
# Come back next morning - 10hrs later.
echo stop >fstop # stop test.
Inspect the files l_date for number of entries and then l_free.
Wonderful - an speeded up soak test that ran for 10hrs last night with flying colours. -
So close to 100K file level access to the USB flash, including append to a single file 72,000 times resulting in a file 17Mbytes.
So that's cool !.
Update July14-0724pst:
Rerunning this test overnight with yesterdays latest update, stoping the test and attempting to remove the USB Flash drive for inspection I get
"Umount failed: 22" or "Invalid argument"
nsh> uname -a
NuttX 17.6 nxd47wk_wkd47tst1_20160713_1444 arm stm32f4discovery
nsh> pwd
/
nsh> ls
/:
dev/
proc/
usb0/
nsh> umount usb0
nsh: umount: umount failed: 22
Update July14-0724pst:
Rerunning this test overnight with yesterdays latest update, stoping the test and attempting to remove the USB Flash drive for inspection I get
"Umount failed: 22" or "Invalid argument"
nsh> uname -a
NuttX 17.6 nxd47wk_wkd47tst1_20160713_1444 arm stm32f4discovery
nsh> pwd
/
nsh> ls
/:
dev/
proc/
usb0/
nsh> umount usb0
nsh: umount: umount failed: 22
Saturday, July 9, 2016
USB Host MSC test using the reference smt32d4discotst1
This is a follow on from previous reference board:
Description: Bring up a USB Host with MSC capability, and store periodic data on it.
Equipment Needed in addition to previous test.
*) a converter cable from USB micro to USB Type A Host
*) A USB Flash drive
The stm32f4discovery board has "USB OTG FS with micro-AB connector".
This supports a USB Full Speed device to connect, and Nuttx drivers support a USB Host MSC capability - ie accessing a flash drive.
$ make menuconfig
# Plug in a Flash drive through the microUSB to USB Type A Receptacle, and look for 'sda'
#### Hurrah - its recognized the USB Flash drive.
#check if it writes to the directory
nsh> help > /usb0/tst1/h.txt
Description: Bring up a USB Host with MSC capability, and store periodic data on it.
Equipment Needed in addition to previous test.
*) a converter cable from USB micro to USB Type A Host
*) A USB Flash drive
The stm32f4discovery board has "USB OTG FS with micro-AB connector".
This supports a USB Full Speed device to connect, and Nuttx drivers support a USB Host MSC capability - ie accessing a flash drive.
$ make menuconfig
System Type--> STM32 Peripheral Support-
[*] OTG FS
Device Drivers-->USB Host Driver Support
[*] Mass Storage Class Support
<exit><exit>
Board Selection--> #notice the following are set
(1024) USB host waiter stack size (NEW)
(100) USB host waiter task priority (NEW)
<exit>
System Type-->USB FS Host Configuration
(128) Rx Packet Size (NEW)
(96) Non-periodic Tx FIFO Size (NEW)
(128) Periodic Tx FIFO size (NEW)
(128) Descriptor Size (NEW)
[ ] Enable SOF interrupts (NEW)
#USB needs a work thread
RTOS Features-->Work queue support CONFIG_SCHED_WORKQUEU
[*] High priority (kernel) worker thread
CONFIG_SCHED_HPWORK
(224) High priority worker thread priority
(NEW)
(50000) High priority worker thread period
(NEW)
(2048) High priority worker thread stack size
(NEW)
<exit>.....<save>
RTOS Features -->Stack and Heap Information
(these values are arbitrarily increased to insure enough ram - FUT needs to be characterized with a stack inspection program some time)
(2048) Idle thread stack size
(4096) Main thread stack size
(2048) Minimum pthread stack size
(2048) Default pthread stack size
RTOS Features -->Stack and Heap Information
(these values are arbitrarily increased to insure enough ram - FUT needs to be characterized with a stack inspection program some time)
(2048) Idle thread stack size
(4096) Main thread stack size
(2048) Minimum pthread stack size
(2048) Default pthread stack size
$mknx.sh
size nuttx
text data bss dec hex filename
86204 308 6148 92660 169f4 nuttx
$stwr
on the stm32f4discovery
uttShell (NSH) NuttX-17.6
nsh>
nsh> ls dev
/dev:
console
null
rtc0
ttyS0
# Plug in a Flash drive through the microUSB to USB Type A Receptacle, and look for 'sda'
nsh> ls dev
/dev:
console
null
rtc0
sda
ttyS0
nsh>
#### Hurrah - its recognized the USB Flash drive.
mount -t vfat /dev/sda /usb0
nsh> ls
/:
dev/
proc/
usb0/
nsh> ls /usb0
/usb0:
System Volume Information/
LOST.DIR/
.....
#### WOW! Reading the directory ####
nsh> mkdir /usb0/tst1
#check if it writes to the directory
nsh> help > /usb0/tst1/h.txt
nsh> cat /usb0/tst1/h.txt
help usage: help [-v] [<cmd>]
[ dirname free mkfifo rm uname
? date help mkrd rmdir umount
basename dd hexdump mh set unset
break df kill mount sh usleep
cat echo ls mv sleep xd
cd exec mb mw test
cp exit mkdir ps time
cmp false mkfatfs pwd true
Builtin Apps:
# What meta info is there about the file? - but no date information
nsh> ls -lRs /usb0/tst1
/usb0/tst1:
-rw-rw-rw- 619 h.txt
nsh>
#Now reset the board, with the USB Host installed, verify the USB Host is recognized and writable.
NuttShell (NSH) NuttX-17.6
nsh> ls /dev
/dev:
console
null
rtc0
sda
ttyS0
nsh> mount -t vfat /dev/sda /usb0
nsh> ls /usb0/tst1
/usb0/tst1:
h.txt
nsh> rm /usb0/tst1/h.txt
nsh> ls /usb0/tst1
/usb0/tst1:
nsh>
#File is gone - so writeable.
# Ok - so lets write to these directories from an app. This requires using an examples application that can be redirected.
$make menuconfig
Application Configuration --->Examples
[*] "Hello, World!" example
(100) Hello task priority (NEW)
(2048) Hello stack size (NEW)
<save><ok><exit>...
$mknx.sh
$stwr
nsh> help
help usage: help [-v] [<cmd>]
[ dirname free mkfifo rm uname
? date help mkrd rmdir umount
basename dd hexdump mh set unset
break df kill mount sh usleep
cat echo ls mv sleep xd
cd exec mb mw test
cp exit mkdir ps time
cmp false mkfatfs pwd true
Builtin Apps:
hello
nsh> hello
Hello, World!!
nsh> mount -t vfat /dev/sda /usb0
nsh> ls
/:
dev/
proc/
usb0/
nsh> free > /usb0/tst1/f.txt
nsh> cat /usb0/tst1/f.txt
total used free largest
Mem: 189120 13552 175568 121392
nsh> hello > /usb0/tst1/h.txt
nsh> cat /usb0/tst1/h.txt
Hello, World!!
nsh>
nsh> hello >> /usb0/tst1/h.txt
nsh>
nsh> cat /usb0/tst1/h.txt
Hello, World!!
Hello, World!!
nsh>
Hello, World!!
nsh>
nsh> hello >> /usb0/tst1/h.txt
nsh>
nsh> cat /usb0/tst1/h.txt
Hello, World!!
Hello, World!!
nsh>
#Wowa - all working nicely (afterNuttx 17.7 or 17.6 afterJuly/7 - bugfix )
<tbd: modify a program to write periodic data to USB Flash>
Reference Test Machine - Stm32F4discovery
When building complex software its essential to do reference builds and designate a reference piece of hardware similar to the final target for testing and keep it in good condition. Too often with out this, testing is done on dodgy hardware that just causes strange problems until reference hardware is established.
My target application is for an IoT data logger, polling sensors "southbound", storing locally on an SDcard, or USB drive, and sending to the internet via serial to a WiFi or Cellular interface
I am using an open source hardware Olimex STM32F4 H407 for prototyping - as its industrial strength and likely to have a good product life. I've created a basic configs/olimex-stm32-h407 but it isn't widely used.
As an alternative hardware, for stability integrating similar functions, I'm choosing the widely available STM32F4discovery that has had a lot of base builds performed on it in nuttx\configs\stm32f4discovery.
It is a demonstration board from ST for trying out their processor..
With the added baseboard this provides a lot of functionality, though I won't be attempting to exercise all the hardware.
For testing you will need
*) USB cable - Type A from the Ubuntu Host to USB mini on the stm32f4discovery card ST
*) USB to TTL/3V logic connector for the the Console - eg adafru.it/954 - also has power if needed.
*) STM baseboard "STM32F4DIS-BB" or Digikey "497-13545-ND"
For the reference build - I'm going to try and build as much of a realistic project as I can for the target environment I'm looking at.
The reference environment starts from configs\stm32f4discovery\nsh\defconfig - and is built up from there.
On my ubuntu machine
$cd git
$mkdir nxhd47tst
$cd nxhd47tst
$nano include/nuttx/.gitignore --> remove /config.h & /version.h
$ size nuttx
text data bss dec hex filename
55961 100 2032 58093 e2ed nuttx
I'm using PA2/PA3 Uart1 for a debug console, so verify
$make menuconfig
System Type-->STM32 Peripheral-->
[*] PWR
[*] SYSCFG
[*] USART2
USART2 Driver Configuration (Standard serial driver) ---> (X) Standard serial driver
Up one level to "System Type"
[*] Exclude CCM SRAM from the heap
[*] Dump stack on assertions
Board Selection
Select target board (STMicro STM32F4-Discovery board) --->
[*] Board LED support
[*] Board button support
(fut) [ ] STM32F4DIS-BB base board
Device Drivers
[ ] Disable driver poll interfaces
[*] Enable /dev/null
[*] RAM Disk Support
-*- SPI Driver Support ---> [*] SPI exchange
[*] Serial Driver Support --->
[*] Enable standard "upper-half" serial driver
[*] Support TIOCSERGSTRUCT
Serial console (USART2) --->
USART2 Configuration --->
(128) Receive buffer size
#enable an enhanced debug I'm enabling a large TX buffer.
(2048) Transmit buffer size
(115200) BAUD rate
(8) Character size
(0) Parity setting
(0) Uses 2 stop bits
[ ] USART2 RTS flow control
[ ] USART2 CTS flow control
[ ] USART2 DMA support
<Save> <Exit> to "Configuration"
File Systems --->
-*- Writable file system
[*] FAT file system
[*] FAT upper/lower names
[ ] FAT long file names
[*] FAT timestamps
<save><exit>
Application Configuration-->NSH Library --> Configure Command Options
[*] df: Enable [-h] man-readable format
<save> <ok> <exit> <exit>
#enable a date facility
Device Drivers-->Timer Driver Support -->RTC Driver Support
[*] Date/Time RTC Support
[ ] RTC Alarm Support (NEW)
[*] RTC Driver Support
[*] RTC IOCTLs
Application Configuration-->NSH Library -->Disablei ndividual Commands
[ ] Disable date # Ensure date turned off
System Type-->RTC clock source (LSI Clock)--> # select Low Speed Internal
<save><ok> <exit> till back to prompt
$mknx.sh # it rebuilds all
$size nuttx
text data bss dec hex filename
73916 244 3972 78132 13134 nuttx
#Now with the USB cable plugged into an stm32F4disco (STM32F407) download it
$stwr
#Connect up a console - I use "Tera Term", open the COM port associated with the F4disco
#On the F4disco press reset should get.
NuttShell (NSH) NuttX-17.6
nsh>
# Type in the following proving the build
nsh> uname -a
NuttX 17.6 nxd47wk_wkd47tst1_20160709_1742 arm stm32f4discovery
#Try help to list cmds with no buildin
nsh> help
help usage: help [-v] [<cmd>]
[ dirname help mkrd rmdir umount
? dd hexdump mh set unset
basename df kill mount sh usleep
break echo ls mv sleep xd
cat exec mb mw test
cd exit mkdir ps time
cp false mkfatfs pwd true
cmp free mkfifo rm uname
Builtin Apps:
nsh>
# Make a ram disk to test writing a file to
mkrd 50
# Try ls dev - and checkout "ram0"
#then type
mkfatfs /dev/ram0
mount -t vfat /dev/ram0 /tmp
# Snap shot this
$git tag -a nxtst17.6_nxd47wk_wkd47tst1_20160709_1820 -m "tag attempt"
$git commit -a -m "version change"
$git push --tags
It can be grabbed with
eg from git
$mkdir wkd47t
$cd wkd47t
My target application is for an IoT data logger, polling sensors "southbound", storing locally on an SDcard, or USB drive, and sending to the internet via serial to a WiFi or Cellular interface
I am using an open source hardware Olimex STM32F4 H407 for prototyping - as its industrial strength and likely to have a good product life. I've created a basic configs/olimex-stm32-h407 but it isn't widely used.
As an alternative hardware, for stability integrating similar functions, I'm choosing the widely available STM32F4discovery that has had a lot of base builds performed on it in nuttx\configs\stm32f4discovery.
It is a demonstration board from ST for trying out their processor..
With the added baseboard this provides a lot of functionality, though I won't be attempting to exercise all the hardware.
For testing you will need
*) USB cable - Type A from the Ubuntu Host to USB mini on the stm32f4discovery card ST
*) USB to TTL/3V logic connector for the the Console - eg adafru.it/954 - also has power if needed.
*) STM baseboard "STM32F4DIS-BB" or Digikey "497-13545-ND"
For the reference build - I'm going to try and build as much of a realistic project as I can for the target environment I'm looking at.
The reference environment starts from configs\stm32f4discovery\nsh\defconfig - and is built up from there.
On my ubuntu machine
$cd git
$mkdir nxhd47tst
$cd nxhd47tst
$git clone git@bitbucket.org:neilh20/anuttx.git nuttx
$git clone git@bitbucket.org:neilh20/nuttapps.git apps
$cd nuttx
$git checkout -b wkd47tst1 #work discoverystm32F407 test
#then I copy the configs\stm32f4discovery to configs\stm32f4discotst
$cd configs
$cp -R stm32f4discovery stm32f4discotst
#Then per my previous blog nuttx-traceable-builds I do the following
~/git/nxd47tst/nuttx (wkd47tst)]$
$nano .gitignore --> remove /.config /.Make.defs
$nano include/nuttx/.gitignore --> remove /config.h & /version.h
$cd tools
$ ./configure.sh stm32f4discotst/nsh
$ cd ..
$ cd ..
$make menuconfig
Build Setup--> Build Host Platform (Linux)
System TypeàSTM32 Periperal Support [ ] OTG FS - disable CONFIG_STM32_OTGFS
$make
verify builds successfully.$ size nuttx
text data bss dec hex filename
55961 100 2032 58093 e2ed nuttx
I'm using PA2/PA3 Uart1 for a debug console, so verify
$make menuconfig
System Type-->STM32 Peripheral-->
[*] PWR
[*] SYSCFG
[*] USART2
USART2 Driver Configuration (Standard serial driver) ---> (X) Standard serial driver
Up one level to "System Type"
[*] Exclude CCM SRAM from the heap
[*] Dump stack on assertions
Board Selection
Select target board (STMicro STM32F4-Discovery board) --->
[*] Board LED support
[*] Board button support
(fut) [ ] STM32F4DIS-BB base board
Device Drivers
[ ] Disable driver poll interfaces
[*] Enable /dev/null
[*] RAM Disk Support
-*- SPI Driver Support ---> [*] SPI exchange
[*] Serial Driver Support --->
[*] Enable standard "upper-half" serial driver
[*] Support TIOCSERGSTRUCT
Serial console (USART2) --->
USART2 Configuration --->
(128) Receive buffer size
#enable an enhanced debug I'm enabling a large TX buffer.
(2048) Transmit buffer size
(115200) BAUD rate
(8) Character size
(0) Parity setting
(0) Uses 2 stop bits
[ ] USART2 RTS flow control
[ ] USART2 CTS flow control
[ ] USART2 DMA support
<Save> <Exit> to "Configuration"
File Systems --->
-*- Writable file system
[*] FAT file system
[*] FAT upper/lower names
[ ] FAT long file names
[*] FAT timestamps
<save><exit>
Application Configuration-->NSH Library --> Configure Command Options
[*] df: Enable [-h] man-readable format
<save> <ok> <exit> <exit>
#enable a date facility
Device Drivers-->Timer Driver Support -->RTC Driver Support
[*] Date/Time RTC Support
[ ] RTC Alarm Support (NEW)
[*] RTC Driver Support
[*] RTC IOCTLs
Application Configuration-->NSH Library -->Disablei ndividual Commands
[ ] Disable date # Ensure date turned off
System Type-->RTC clock source (LSI Clock)--> # select Low Speed Internal
<save><ok> <exit> till back to prompt
$mknx.sh # it rebuilds all
$size nuttx
text data bss dec hex filename
73916 244 3972 78132 13134 nuttx
#Now with the USB cable plugged into an stm32F4disco (STM32F407) download it
$stwr
#Connect up a console - I use "Tera Term", open the COM port associated with the F4disco
#On the F4disco press reset should get.
NuttShell (NSH) NuttX-17.6
nsh>
# Type in the following proving the build
nsh> uname -a
NuttX 17.6 nxd47wk_wkd47tst1_20160709_1742 arm stm32f4discovery
#Try help to list cmds with no buildin
nsh> help
help usage: help [-v] [<cmd>]
[ dirname help mkrd rmdir umount
? dd hexdump mh set unset
basename df kill mount sh usleep
break echo ls mv sleep xd
cat exec mb mw test
cd exit mkdir ps time
cp false mkfatfs pwd true
cmp free mkfifo rm uname
Builtin Apps:
nsh>
# Make a ram disk to test writing a file to
mkrd 50
# Try ls dev - and checkout "ram0"
#then type
mkfatfs /dev/ram0
mount -t vfat /dev/ram0 /tmp
nsh>ls dev
nsh>ls tmp
nsh>help > /tmp/h.txt
nsh>cat /tmp/h.txt
#Hurrah created and wrote a text file to a temp directory.
#List the df in human readable form
df -h
Filesystem Size Used Available Mounted on
vfat 7680B 1K 6656B /tmp
nsh> free
total used free largest
Mem: 191376 33264 158112 123648
$git tag -a nxtst17.6_nxd47wk_wkd47tst1_20160709_1820 -m "tag attempt"
$git commit -a -m "version change"
$git push --tags
It can be grabbed with
eg from git
$mkdir wkd47t
$cd wkd47t
$git clone git@bitbucket.org:neilh20/anuttx.git nuttx
$git clone git@bitbucket.org:neilh20/nuttapps.git apps
$cd nuttx
$git checkout wkd47tst1
$git checkout nxtst17.6_nxd47wk_wkd47tst1_20160709_1820
$make
<download>
<make any modifications and switch it to your own branch with>
$git checkout nxtst17.6_nxd47wk_wkd47tst1_20160709_1820
$make
<download>
<make any modifications and switch it to your own branch with>
git checkout -b <mybranch>
Subscribe to:
Posts (Atom)