Picon

STM32F103 dev board

Hi,

I'm about to make nuttx running on a STM32F103 development board from china [1],[2] but I don't get nsh shell to connect to. The board is not even registering to my linux pc as it should be and is detected as an unknown usb device. But I expect the board as an CDC/ACM device.

I used the stm32_tiny [2] config because it is equipped with the same processor and just has an additional wireless module which is deactivated because CONFIG_WL_NRF24L01 is not set. I also checked the other configuration via "make menuconfig" and it seems to be ok - nsh should be activated to listen to USB.

Compiling works and flashing via stlink_v2 works as well:
st-flash write nuttx.bin 0x8000000 2015-05-02T21:42:10 INFO src/stlink-common.c: Loading device parameters.... 2015-05-02T21:42:10 INFO src/stlink-common.c: Device connected is: F1 Medium-density device, id 0x20036410 2015-05-02T21:42:10 INFO src/stlink-common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x20000 bytes (128 KiB) in pages of 1024 bytes 2015-05-02T21:42:10 INFO src/stlink-common.c: Attempting to write 50012 (0xc35c) bytes to stm32 address: 134217728 (0x8000000) Flash page at addr: 0x0800c000 erased 2015-05-02T21:42:11 INFO src/stlink-common.c: Finished erasing 49 pages of 1024 (0x400) bytes 2015-05-02T21:42:11 INFO src/stlink-common.c: Starting Flash write for VL/F0/F3 core id 2015-05-02T21:42:11 INFO src/stlink-common.c: Successfully loaded flash loader in sram 48/48 pages written 2015-05-02T21:42:14 INFO src/stlink-common.c: Starting verification of write complete 2015-05-02T21:42:15 INFO src/stlink-common.c: Flash written and verified! jolly good!According to the datasheet [3] the flash memory starts at address 0x800000 and the the BOOT0 pin is jumpered to ground, so it should boot from flash as well.

Any ideas what I might have missed or why it is not working the way it should?

[1] http://www.aliexpress.com/item/1pcs-NEW-ARM-Cortex-M3-STM32F103C8T6-STM32-Minimum-System-Development-Board-Newest/2029958379.html

[2] http://www.olliw.eu/2013/stm32 -this-and-that/#lctech103c8

[3] http://www.st.com/web/catalog/mmc/FM141/SC1169/SS1031/LN1565/PF164476


Thanks,

Max



__._,_.___
Posted by: airmaxat-/E1597aS9LQAvxtiuMwx3w@public.gmane.org



__,_._,___
Picon

Crash when running ramtest. [2 Attachments]

Hello,


I'm having a crash on ramtest when running on STM32 STM32F429I-Discovery board. 

The crash only happens when I enable the  Memory Manager Debug Output. If it is disabled the crash does not happen. Please see the logs attached.

I found it because I had to enable the Memory Manager Debug Output when testing my application heap allocation.

Does any body have any clue?



PS: The problem is probably related with some issue with debug code, once I run the ramtest without arguments(It should only print the usage and exit).


br.,

Bruno






 



__._,_.___

Attachment(s) from bruherrera-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org [nuttx] | View attachments on the web

2 of 2 File(s)

Posted by: bruherrera-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org



__,_._,___
Picon

more drivers of PWM


Hi,

I'm working with STM32F4DISCOVERY platform and i am trying to create 4 devices PWM, ran the example and worked well, created more3devices in file configs/stm32f4discovery/src/stm32_pwm.c, but when i create i try to run the example says that there is no .


I tried to create a root of example only for the default device (/dev/pwm0) and this works perfectly well, but when i try to add another devicePWM, this also does not work.


I also added the respective timer associated with each new device as was done for the default device in configs/
/stm32f4discovery/src/stm32f4discovery.h, even after all these changes still does not work, even now the default device works. When i run the example PWM or i created gives me the following:

  -> "Pwm_main: boardctl failed: 19"



Lack change some more file or do some more enable?




__._,_.___
Posted by: calca_chibos-/E1597aS9LQAvxtiuMwx3w@public.gmane.org



__,_._,___
Picon

Nice new platform for nuttx? [1 Attachment]

<*>[Attachment(s) from Sebastien Lorquet included below]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

https://www.kickstarter.com/projects/rabidprototypes/neutrino-the-tiny-3
2-bit-arduino-zero-compatible/

Looks interesting, Atmel ATSAMD21G18 ARM Cortex M0+ , 256k flash and
32k ram, small form factor!

Sebastien
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBAgAGBQJVQ5C+AAoJEJFP1HbJm5DnXcMH/2AauShLowUtlWTB1aivqGnN
1g1DQ2q8MKovptzZb4RDrxHkcr8FsgOZpD3e7pbQfbNtoEeKv31lbDFciqUUCqo1
tYmXL+VUNN7fszlkXX/tZfDTs3WnrxOHA3JAupNdIMhojQFmsZOUKSFmTr25hyFD
J44y9XXRBrndoSfya3zMLEQX44Gzqmmeqed94a6UYfBXQhh+4PK0SG0bAz0WiBmz
WWnNtk1CkhrL22sFxSOYxOYdRhDwUB/I8cMo6O6q/WSo9XoQp7g6OfwHCtDhZLnT
cJCIza0kHmg+fVsYG+GW7L6iv5WgCsBpTrAc7bC2H3o7NlRhVyQ3bHH9dCly+eU=
=VLO0
-----END PGP SIGNATURE-----

<*>Attachment(s) from Sebastien Lorquet:

<*> 1 of 1 File(s)
https://groups.yahoo.com/neo/groups/nuttx/attachments/284649955;_ylc=X3oDMTJyYWdwdnIwBF9TAzk3MzU5NzE0BGdycElkAzIzMzg5MDcwBGdycHNwSWQDMTcwNTAwNjU1OQRzZWMDYXR0YWNobWVudARzbGsDdmlld09uV2ViBHN0aW1lAzE0MzA0OTEzMzI- 
  <*> 0xC99B90E7.asc

------------------------------------
Posted by: Sebastien Lorquet <sebastien@...>
------------------------------------

------------------------------------

Yahoo Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/nuttx/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/nuttx/join
    (Yahoo! ID required)

<*> To change settings via email:
    nuttx-digest@... 
    nuttx-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
    nuttx-unsubscribe@...

<*> Your use of Yahoo Groups is subject to:
    https://info.yahoo.com/legal/us/yahoo/utos/terms/

Picon

[PATCH] stm32f3: Fix GPIOD memory map defines [1 Attachment]

Discovered this issue the hard way today when my configuration of GPIOs on Port D were not working. The attached patch fixes the STM32_GPIOD_BASE defines for both the stm32f30xxx and stm32f37xxx, resulting in the configuration being written to the correct memory location.


Greg Meiste



__._,_.___

Attachment(s) from greg.meiste-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org [nuttx] | View attachments on the web

1 of 1 File(s)

Posted by: greg.meiste-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org



__,_._,___
Picon

ELF Binary Loader and binaries with C++ exceptions on STM32F4Discovery [4 Attachments]

<*>[Attachment(s) from Leo included below]

Hi,
   I've managed to make the elf binary loader
work with my application (C++ using uClibc++
with exceptions).

It wouldn't work failing because the elf loader
didn't recognize the R_ARM_TARGET2 relocation
type for a section.
R_ARM_TARGET2 is related to exception handling.

I've searched around to understand how that
relocation type should be performed; but I'm
having no luck.

The good news is that with this minor patch
(attached) C++ application using exceptions
compiles and runs ok.

The bad news is that exception handling is
not working (although the execution fails
gracefully: the process quits and control
returns to nsh).

With the same application built inside the
firmware the exception execution path works fine.

In the elf version I'm unable to debug the
relocated binary code (is it possible to do
that?) where the catch {} code is located.

Anyway, I've found confusing information about
how to relocate the R_ARM_TARGET2 sections;
in [1] (page 13) it says that is the same as
R_ARM_ABS32.
In [2] it says it can be relocated in different
ways, and for arm*-*-eabi it defaults to R_ARM_REL32.

I'm absolutely no expert with ELF, and relocation
issues; anyway I've added the R_ARM_REL32 case
following the formulas in nuttx/arch/arm/include/elf.h
If R_ARM_ABS32 is (S + A) | T
and R_ARM_REL32 is ((S + A) | T) - P
with "P is the address of the place being relocated (derived from r_offset)"

I've just subtracted rel->r_offset; to the addr.

I've tested using TARGET2 as ABS32. but the catch{} is
not reached.

Neither when using TARGET2 as REL32.

I don't know how to tackle the problem. The biggest issue
is not being able to debug the loaded binary.

Still, it is good thing to be able to load a binary using exceptions.

Note1:
I'm using the gcc-arm-none-eabi-4_9-2014q4-20141203-src.tar.bz2
toolchain.

Note2:
I didn't send the patch related to the symtab because I don't know how
to cleanly handle it.
At the moment the symtab is set on nsh_main.c.
Is it the right place?
Maybe on os_start() would be better (there is an unused lib_initialize()
that looks like the right place if CONFIG_LIBC_EXECFUNCS and
CONFIG_EXECFUNCS_HAVE_SYMTAB are defined ).

Leo.

[1]:
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0038a/IHI0038A_ehabi.pdf
[2]: https://sourceware.org/binutils/docs-2.24/ld/ARM.html#ARM

<*>Attachment(s) from Leo:

<*> 4 of 4 File(s)
https://groups.yahoo.com/neo/groups/nuttx/attachments/572420912;_ylc=X3oDMTJyYTVycGV2BF9TAzk3MzU5NzE0BGdycElkAzIzMzg5MDcwBGdycHNwSWQDMTcwNTAwNjU1OQRzZWMDYXR0YWNobWVudARzbGsDdmlld09uV2ViBHN0aW1lAzE0MzA0MDg0MzM- 
  <*> Added-RARMTARGET2-and-RARMREL32-relocation-types.patch
  <*> ELF_support_for_STM32F4DISCOVERY.patch
  <*> Fixed-wrong-debugging-printf-values.patch
  <*> initialize_elf_binary_loader.patch

------------------------------------
Posted by: Leo <aloe3132@...>
------------------------------------

------------------------------------

Yahoo Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/nuttx/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/nuttx/join
    (Yahoo! ID required)

<*> To change settings via email:
    nuttx-digest@... 
    nuttx-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
    nuttx-unsubscribe@...

<*> Your use of Yahoo Groups is subject to:
    https://info.yahoo.com/legal/us/yahoo/utos/terms/

Picon

[PATCH] stm32: Add support for setting PVD level and interrupt [1 Attachment]

Hi Greg,


Patch adds support for STM32's Programmable Voltage Detector feature. I put register access behind CONFIG_STM32_ENERGYLITE as have not checked F1/F2/F4 etc. manuals. Tested on STM32L1. PVD interrupt looks generic, at least #defines it needs are in headers for every chip variant.


- Juha



__._,_.___

Attachment(s) from Juha Niskanen (Haltian) | View attachments on the web

1 of 1 File(s)

Posted by: "Juha Niskanen (Haltian)" <juha.niskanen-1vFRZQwJeV1BDgjK7y7TUQ@public.gmane.org>



__,_._,___
Picon

Question re: task scheduling...

Hello,


I am playing around with the Nuttx task scheduling and created a little program like the following...


void Task1(void)
{
  static int i;


  while (1)
    {
        lowsyslog("Task1 talking...\n");
    }
}

void Task2(void)
{
  int i;

  while (1)
    {
        lowsyslog("Task2 talking...\n");
    }

}


int main(int argc, char **argv)
{
&nbsp ; char *task1_argv[2];
  pid_t task1_pid;
  char *task2_argv[2];
  pid_t task2_pid;

  task1_argv[0] =
task1_arg;
 
task1_argv[1] = 0;
 
task1_pid = task_create(task1_name, 60, 2048, Task1, (FAR char * const *)task1_argv);
  if (
task1_pid < 0)
    {
      printf("main: task1 creation failed: %d\n", errno);
    }

  task2_argv[0] = task2_arg;
 
task2_argv[1] = 0;
 
task2_pid = task_create(task2_name, 60, 2048, Task2, (FAR char * const *)task2_argv);
  if (
task2_pid < 0)
    {
      printf("main: task2 creation failed: %d\n", errno);
    }


  return 0;
}


I noticed that the task2 never gets a chance to run. I believe it is because the scheduler uses the FIFO scheduling. However, the round robin timeout (CONFIG_RR_INTERVAL) is set to 200ms so I expect the Task2 should be getting the chance to run, should it?


Anyhow, pan>what is the right way to make the Task1 and Task2 running with equal chances?


Thanks.

 



__._,_.___
Posted by: valont.valont-/E1597aS9LQAvxtiuMwx3w@public.gmane.org



__,_._,___
Picon

Unused variable when not using IPV6 [1 Attachment]

<*>[Attachment(s) from SP included below]

If IPV6 is not enabled, an warning occurs for an unused variable, which
is currently used inside the IPV6 block, but declared outside:

  socket/recvfrom.c: In function 'recvfrom_udpsender':
  socket/recvfrom.c:963:22: warning: unused variable 'fromlen'
[-Wunused-variable]
         FAR socklen_t *fromlen = pstate->rf_fromlen;

Its only minor, but heck.. I've included a patch. Hope it doesn't
violate the coding style.

-- 
	SP

<*>Attachment(s) from SP:

<*> 1 of 1 File(s)
https://groups.yahoo.com/neo/groups/nuttx/attachments/245188444;_ylc=X3oDMTJyM3BrM3JyBF9TAzk3MzU5NzE0BGdycElkAzIzMzg5MDcwBGdycHNwSWQDMTcwNTAwNjU1OQRzZWMDYXR0YWNobWVudARzbGsDdmlld09uV2ViBHN0aW1lAzE0MzAxNTAwNzE- 
  <*> recvfrom-fromlen-ipv6.c

------------------------------------
Posted by: SP <sp@...>
------------------------------------

------------------------------------

Yahoo Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/nuttx/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/nuttx/join
    (Yahoo! ID required)

<*> To change settings via email:
    nuttx-digest@... 
    nuttx-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
    nuttx-unsubscribe@...

<*> Your use of Yahoo Groups is subject to:
    https://info.yahoo.com/legal/us/yahoo/utos/terms/

Picon

Is it ok to have a separate buffer for IP and MAC layer ?

 HI,


I am thinking to perform some changes in the net stack. Can you guys please let me know whether there is any disadvantage of doing the following changes in the architectural/design/RTOS way ?


1. Existing stack has single buffer of d_buf and its being used from device level till IP level for the processing. Even though the computation of process from phy to IP level is in milli seconds, if at all any packet reaches in this time from the radio channel, it will drop it(thearitically atleast).

Also the existing approach is best for mem management since the complete flow is single threaded and having multiple buffer does not makes sense.


New approach:

1. Split the buffer from mac level and IP level. 

  & nbsp;In the mac level have queue to store the recieved packets (keep the queue size taking consideration of RAM and keep it for small, say 30 packets max).

2. Spawn network stack in new thread, which ll fetch the packets from this queue.

3. Receiver will put the packets in this queue when ever the packet gets received in radio channel.


Our goal is reliability here without disturbing the actual current performance. 


Please provide your input in the design and RTOS principles level whether its okay to go ahead ??


Thanks




__._,_.___
Posted by: rajuuu1992-/E1597aS9LQAvxtiuMwx3w@public.gmane.org



__,_._,___
Picon

reducing nuttx.bin size tips?

Sorry folks, I'm a newbie and didn't find anything obvious in the docs or this group's archives. I'm trying to build nuttx.bin for the C139 phone and think I have a limitation of 128k (due to some issue with the highram loader) but the image comes to around 148k. I'm wondering if there are any tips on reducing size.

Currently I have used the default ./configure.sh compal_e86/nsh_highram. I've tried removing a few things here and there but only managed to get things down to about 138k.

Wondering if there's some big bang for the buck item to remove.

The alternative obviously is to debug the compal loader or make an alternate loader or pursue flashing nuttx.

Thanks,
Craig




__._,_.___
Posted by: craig_comstock-/E1597aS9LQAvxtiuMwx3w@public.gmane.org



__,_._,___

Gmane