You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nuttx.apache.org by Bernd Walter <ti...@cicely7.cicely.de> on 2020/11/02 12:13:20 UTC
Re: Problems and a bug in samd2l2 ADC code
On Fri, Oct 30, 2020 at 12:26:33PM +0100, Bernd Walter wrote:
> On Thu, Oct 29, 2020 at 07:39:16PM -0300, Alan Carvalho de Assis wrote:
> > Ok, now I understood the issue you found
> >
> > Yes, arch/arm/include/samd2l2/sam_adc.h is wrong.
> >
> > I think this file shouldn't exit, it doesn't exist to other arches.
>
> OK - I will take a look into this and change it to match other arches.
> But I like to find the other ADC problem before I rearrange the code.
> Might take a few days.
Well, thiss is all weird.
My Chip is a SAMD21E17A, so it has only 16k RAM.
I had been using in in another project with my own IO code and NXFFS on
an SPI flash (W25), but had to reduce stack sizes to have enough RAM
for the NXFFS.
This was with old NuttX code, shortly before the Apache change.
This project runs on a similar board, but uses different IO.
One of the IOs I need is the ADC and NuttX had no ADC support for the
SAMD21 in the code I had been using, therefor I upgraded in that project.
I'm running FreeBSD and had to work arround a few additional Linuxisms,
like calling "make" from a shell script and expect it to be GNU make.
Anyways - the board is tight on IO Pins and I have no UART left for console.
I did all my debugging with gdb and a bunch of LEDs.
This is the first part of my main routine:
int
main()
{
tm16_init();
// // enable first digit as test
// for (;;) {
// tm16_setbmp(3, 0x01);
// usleep(100);
// }
//
LED_data[STATUS_LED] = 1;
LED_data[ERROR_LED] = 1;
LED_out();
LED_out();
sleep(1);
LED_data[ERROR_LED] = 0;
LED_out();
boardctl(BOARDIOC_INIT, 0);
config_init();
serial_init();
#ifdef CONFIG_SAMD2L2_ADCx
if (sam_adc_setup() < 0) {
syslog(LOG_ERR, "Failed to initialize the ADC driver\n");
}
#endif
...
tm16_init is just bit bang, also LED_out(), which delivers data to the tm1653
chip I'm using to drive the LEDs.
config_init() tries to read json config file from NXFFS, which should have been
mounted after boardctl.
serial_init() is empty for later use.
Up until sam_adc_setup gets called, /dev/null gets init, the via
board_app_initialize() I mount procfs and my SPI flash.
When sam_adc_setup() gets called somehow the inodes tables it searches in
seem to be corrup, at least the result makes no sense for me, but I don't
understand that code path and memory structures well enough yet.
If I call sam_adc_setup() before boardctl() it does init, but fails to
open later when I try to use it.
Then I thought, lets reduce memory usage and don't mount the NXFFS for now.
Without that (which also inits the SPI), it never returns from boardctl().
I'm open for ideas.
My current plan is to setup a Linux system and try plain NuttX on an
Arduino Zero.
> > Its content should be inside the arch/arm/src/samd2l2/sam_adc.h
> >
> > BR,
> >
> > Alan
> >
> > On 10/29/20, Bernd Walter <ti...@cicely7.cicely.de> wrote:
> > > On Thu, Oct 29, 2020 at 06:33:46PM -0300, Alan Carvalho de Assis wrote:
> > >> I don't think it is wrong.
> > >
> > > Well - inlcuding and requiring two files with the same protector clearly
> > > is wrong.
> > >
> > >> See: arch/arm/src/stm32/stm32_adc.h
> > >
> > > There is no arch/arm/include/stm32/stm32_adc.h
> > > There is a arch/arm/src/stm32/hardware/stm32_adc.h, which uses
> > > __ARCH_ARM_SRC_STM32H7_HARDWARE_STM32_ADC_H, so no collision
> > >
> > > arch/arm/include/samd2l2/sam_adc.h
> > > arch/arm/src/samd2l2/sam_adc.h
> > > Both use the same protector
> > > There is also arch/arm/src/samd2l2/hardware/samd_adc.h, which uses
> > > __ARCH_ARM_SRC_SAMD2L2_HARDWARE_SAMD_ADC_H, so no collision with
> > > this file.
> > >
> > > arch/arm/include/samd2l2/sam_adc.h used to be named adc.h with
> > > a matching protector name and originally had no collision.
> > >
> > >>
> > >> Now look inside boards/arm/stm32/ and you will find many board that
> > >> includes this file same way.
> > >
> > > As I said - there is no arch/arm/include/stm32/stm32_adc.h
> > > This is likely very unique to those two archs:
> > > [239]cicely7> ls -al arch/arm/include/*/*adc.h
> > > -rw-r--r-- 1 ticso 1000 3395 Oct 29 20:42 arch/arm/include/cxd56xx/adc.h
> > > -rw-r--r-- 1 ticso 1000 2798 Oct 29 20:42
> > > arch/arm/include/samd2l2/sam_adc.h
> > >
> > > As you can see, the cxd56xx isn't prefixed, which is the same it had been
> > > for the samd2l2 until 6bff1f4df4ae3e4fc21d7d98afdbfdcc855a6ed2 changed the
> > > filename and protector name.
> > >
> > >> On 10/29/20, Bernd Walter <ti...@cicely7.cicely.de> wrote:
> > >> > On Thu, Oct 29, 2020 at 05:42:58PM -0300, Alan Carvalho de Assis wrote:
> > >> >> Hello,
> > >> >>
> > >> >> On 10/29/20, Bernd Walter <ti...@cicely7.cicely.de> wrote:
> > >> >> > On Thu, Oct 29, 2020 at 08:51:13AM -0300, Alan Carvalho de Assis
> > >> >> > wrote:
> > >> >> >> Hi Bernd,
> > >> >> >>
> > >> >> >> It was "working" few mont ago. I put working covered by quotes
> > >> >> >> because
> > >> >> >> the ADC convertion wasn't linear. I think the calibration process
> > >> >> >> was
> > >> >> >> failing.
> > >> >> >
> > >> >> > arch/arm/src/samd2l2/sam_adc.h was previously named
> > >> >> > arch/arm/src/samd2l2/adc.h
> > >> >> > With the rename the protector define was updated to be identic to
> > >> >> > the
> > >> >> > one
> > >> >> > in arch/arm/src/samd2l2/sam_adc.h
> > >> >> > https://github.com/apache/incubator-nuttx/commit/6bff1f4df4ae3e4fc21d7d98afdbfdcc855a6ed2
> > >> >> >
> > >> >> > No idea what the convention for the fix would be, beside not using
> > >> >> > the
> > >> >> > same
> > >> >> > protector name.
> > >> >> >
> > >> >>
> > >> >> Well, the sam_adc.h appears correct and the #ifdef protection appears
> > >> >> correct too.
> > >> >
> > >> > It is correct by itself, but not in the bigger context:
> > >> > arch/arm/include/samd2l2/sam_adc.c:
> > >> > ...
> > >> > #include <arch/chip/sam_adc.h>
> > >> > ...
> > >> > #include "sam_adc.h"
> > >> >
> > >> > Both included files have the same filename and use the same #define to
> > >> > protect.
> > >> > The first gets included and the content of the second is then missing.
> > >> >
> > >> >>
> > >> >> >> I tested it on Arduino Zero board (SAMD21).
> > >> >> >
> > >> >> > Ok - I do have an Arduino Zero board to test on.
> > >> >> > The second problem is puzzling me.
> > >> >> > For my board code I copied
> > >> >> > boards/arm/samd2l2/arduino-m0/src/sam_adc.c
> > >> >> > It calls adc_register with "/dev/adc0", which calls
> > >> >> > register_driver),
> > >> >> > in which inode_reserve() then fails with EEXIST.
> > >> >> > This is common code for all platforms, which fails.
> > >> >> >
> > >> >>
> > >> >> The EEXIST error means that the file already exist and then probably
> > >> >> the ADC was registers twice. Maybe sam_adc_setup() was called twice or
> > >> >> it is called once but adc_register("/dev/adc0") is called from other
> > >> >> place.
> > >> >
> > >> > Thanks you for the hints.
> > >> > Chaning the path didn't work, but did no further tests today.
> > >> >
> > >> >> Try to enable CONFIG_DEBUG_ANALOG_INFO and see if it will give you
> > >> >> some
> > >> >> hints.
> > >> >>
> > >> >> BR,
> > >> >>
> > >> >> Alan
> > >> >
> > >> > --
> > >> > B.Walter <be...@bwct.de> http://www.bwct.de
> > >> > Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
> > >> >
> > >
> > > --
> > > B.Walter <be...@bwct.de> http://www.bwct.de
> > > Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
> > >
>
> --
> B.Walter <be...@bwct.de> http://www.bwct.de
> Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
--
B.Walter <be...@bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
Re: Problems and a bug in samd2l2 ADC code
Posted by Bernd Walter <ti...@cicely7.cicely.de>.
On Wed, Nov 04, 2020 at 06:56:50PM -0300, Alan Carvalho de Assis wrote:
> Hi Bernd,
>
> Did you disable the serial console?
>
> CONFIG_NO_SERIAL_CONSOLE=y (Device Drivers -> Serial Driver Support ->
> Serial console (No serial console) ).
[194]nuttx-devel> grep CONSOLE contrib/nuttx/.config
# CONFIG_DEV_CONSOLE is not set
# CONFIG_SERIAL_CONSOLE is not set
Don't have that option avaiable.
CONFIG_SERIAL=y
This one is still enabled, although I think I don't need it.
The board has no NuttX UART on the controller enabled.
I do run SERCOM3 as UART, but because of strict Modbus/RTU timing in
my own code.
SERCOM0 is SPI for W25Q16 used with NXFFS
SERCOM1 is I2C for FM24CL16 used for raw access
SERCOM2 is disabled and no available pins to use it.
SERCOM3 out of NuttX
--
B.Walter <be...@bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
Re: Problems and a bug in samd2l2 ADC code
Posted by Alan Carvalho de Assis <ac...@gmail.com>.
Hi Bernd,
Did you disable the serial console?
CONFIG_NO_SERIAL_CONSOLE=y (Device Drivers -> Serial Driver Support ->
Serial console (No serial console) ).
BR,
Alan
On 11/3/20, Bernd Walter <ti...@cicely7.cicely.de> wrote:
> On Tue, Nov 03, 2020 at 03:34:46PM +0100, Bernd Walter wrote:
>> On Mon, Nov 02, 2020 at 03:09:12PM +0100, Bernd Walter wrote:
>> > On Mon, Nov 02, 2020 at 10:17:41AM -0300, Alan Carvalho de Assis wrote:
>> > > This should be a better idea because you will have 32KB of RAM. They
>> > > after getting it working you can remove not necessary features to
>> > > eventually get it working reliable on 16KB RAM.
>>
>> Ok - on the Zero and with predefined config (plus options to enable ADC
>> and
>> the workarround for the include files), it works.
>> Have to see if the problem just didn't appear or if it is somehow related
>> to my setup.
>
> Wow - that was very unexpected.
> I've stripped my code to nearly nothing.
> Stack sizes had been restored to original NuttX values
> board_app_initialize did (almost) nothing.
> My main only called boardctl(BOARDIOC_INIT, 0); and then in config_init()
> It hang in stat because of a broken inode table.
>
> This is my config_init btw:
> static
> void
> config_init()
> {
> #ifdef HAVE_W25
> FILE *f;
> ssize_t len;
>
> struct stat st;
> if (stat(CONFIGFILE, &st) == 0) {
> len = st.st_size;
> f = fopen(CONFIGFILE, "rb");
> if (f != NULL) {
> syslog(LOG_NOTICE, "json reading %d bytes\n", len);
> char *data = malloc(len + 1);
> if (data != NULL) {
> len = fread(data, 1, len, f);
> if (len >= 0) {
> data[len] = '\0';
> } else {
> free(data);
> data = NULL;
> }
> }
> fclose(f);
>
> if (data != NULL) {
> syslog(LOG_NOTICE, "json data read: %s\n",
> data);
> json_config = cJSON_Parse(data);
> free(data);
> }
> }
> }
> #endif
> if (json_config == NULL) {
> syslog(LOG_NOTICE, "reseting json config\n");
> json_config = cJSON_CreateObject();
> }
> }
>
> Nothing fancy - HAVE_W25 was set, but the mounting code in
> board_app_initialize() disabled.
>
> And then there it was, the only thing left in board_app_initialize():
> printf("test\n\r");
>
> I do not have a console and obviously stdio wasn't linked to /dev/null.
> This wasn't a problem on my other console less board using older NuttX, but
> with memory corruption I also just might have been lucky.
>
> Is there any example on how to link /dev/null?
>
> --
> B.Walter <be...@bwct.de> http://www.bwct.de
> Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
>
Re: Problems and a bug in samd2l2 ADC code
Posted by Bernd Walter <ti...@cicely7.cicely.de>.
On Tue, Nov 03, 2020 at 03:34:46PM +0100, Bernd Walter wrote:
> On Mon, Nov 02, 2020 at 03:09:12PM +0100, Bernd Walter wrote:
> > On Mon, Nov 02, 2020 at 10:17:41AM -0300, Alan Carvalho de Assis wrote:
> > > This should be a better idea because you will have 32KB of RAM. They
> > > after getting it working you can remove not necessary features to
> > > eventually get it working reliable on 16KB RAM.
>
> Ok - on the Zero and with predefined config (plus options to enable ADC and
> the workarround for the include files), it works.
> Have to see if the problem just didn't appear or if it is somehow related
> to my setup.
Wow - that was very unexpected.
I've stripped my code to nearly nothing.
Stack sizes had been restored to original NuttX values
board_app_initialize did (almost) nothing.
My main only called boardctl(BOARDIOC_INIT, 0); and then in config_init()
It hang in stat because of a broken inode table.
This is my config_init btw:
static
void
config_init()
{
#ifdef HAVE_W25
FILE *f;
ssize_t len;
struct stat st;
if (stat(CONFIGFILE, &st) == 0) {
len = st.st_size;
f = fopen(CONFIGFILE, "rb");
if (f != NULL) {
syslog(LOG_NOTICE, "json reading %d bytes\n", len);
char *data = malloc(len + 1);
if (data != NULL) {
len = fread(data, 1, len, f);
if (len >= 0) {
data[len] = '\0';
} else {
free(data);
data = NULL;
}
}
fclose(f);
if (data != NULL) {
syslog(LOG_NOTICE, "json data read: %s\n", data);
json_config = cJSON_Parse(data);
free(data);
}
}
}
#endif
if (json_config == NULL) {
syslog(LOG_NOTICE, "reseting json config\n");
json_config = cJSON_CreateObject();
}
}
Nothing fancy - HAVE_W25 was set, but the mounting code in
board_app_initialize() disabled.
And then there it was, the only thing left in board_app_initialize():
printf("test\n\r");
I do not have a console and obviously stdio wasn't linked to /dev/null.
This wasn't a problem on my other console less board using older NuttX, but
with memory corruption I also just might have been lucky.
Is there any example on how to link /dev/null?
--
B.Walter <be...@bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
Re: Problems and a bug in samd2l2 ADC code
Posted by Alan Carvalho de Assis <ac...@gmail.com>.
Hi Bernd,
On 11/3/20, Bernd Walter <ti...@cicely7.cicely.de> wrote:
> On Mon, Nov 02, 2020 at 03:09:12PM +0100, Bernd Walter wrote:
>> On Mon, Nov 02, 2020 at 10:17:41AM -0300, Alan Carvalho de Assis wrote:
>> > This should be a better idea because you will have 32KB of RAM. They
>> > after getting it working you can remove not necessary features to
>> > eventually get it working reliable on 16KB RAM.
>
> Ok - on the Zero and with predefined config (plus options to enable ADC and
> the workarround for the include files), it works.
> Have to see if the problem just didn't appear or if it is somehow related
> to my setup.
>
Great! Nice to hear that it works on Arduino Zero board!
Now you can "strip" your config! :-D
BR,
Alan
Re: Problems and a bug in samd2l2 ADC code
Posted by Bernd Walter <ti...@cicely7.cicely.de>.
On Mon, Nov 02, 2020 at 03:09:12PM +0100, Bernd Walter wrote:
> On Mon, Nov 02, 2020 at 10:17:41AM -0300, Alan Carvalho de Assis wrote:
> > This should be a better idea because you will have 32KB of RAM. They
> > after getting it working you can remove not necessary features to
> > eventually get it working reliable on 16KB RAM.
Ok - on the Zero and with predefined config (plus options to enable ADC and
the workarround for the include files), it works.
Have to see if the problem just didn't appear or if it is somehow related
to my setup.
--
B.Walter <be...@bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
Re: Problems and a bug in samd2l2 ADC code
Posted by Alan Carvalho de Assis <ac...@gmail.com>.
Hi Bernd,
On 11/2/20, Bernd Walter <ti...@cicely7.cicely.de> wrote:
sic
>
> Well, thiss is all weird.
> My Chip is a SAMD21E17A, so it has only 16k RAM.
> I had been using in in another project with my own IO code and NXFFS on
> an SPI flash (W25), but had to reduce stack sizes to have enough RAM
> for the NXFFS.
Well, 16KB is really the bottom line, you probably will face issues
because you are trying to add fancy things like json, etc. I don't
suggest people to use NuttX on MCUs with less than 32KB because at end
of the day they will want to add some other subsystem to their
firmware and things will not work well.
> This was with old NuttX code, shortly before the Apache change.
> This project runs on a similar board, but uses different IO.
> One of the IOs I need is the ADC and NuttX had no ADC support for the
> SAMD21 in the code I had been using, therefor I upgraded in that project.
> I'm running FreeBSD and had to work arround a few additional Linuxisms,
> like calling "make" from a shell script and expect it to be GNU make.
> Anyways - the board is tight on IO Pins and I have no UART left for
> console.
In the past NuttX had a better support to BSDs because we used to have
a contributor that was running OpenBSD. If you want to help to make
NuttX run better on FreeBSD and other, please submit a patch to fix
it. :-)
> I did all my debugging with gdb and a bunch of LEDs.
> This is the first part of my main routine:
> int
> main()
> {
> tm16_init();
> // // enable first digit as test
> // for (;;) {
> // tm16_setbmp(3, 0x01);
> // usleep(100);
> // }
> //
> LED_data[STATUS_LED] = 1;
> LED_data[ERROR_LED] = 1;
> LED_out();
> LED_out();
> sleep(1);
> LED_data[ERROR_LED] = 0;
> LED_out();
>
> boardctl(BOARDIOC_INIT, 0);
>
> config_init();
>
> serial_init();
>
> #ifdef CONFIG_SAMD2L2_ADCx
> if (sam_adc_setup() < 0) {
> syslog(LOG_ERR, "Failed to initialize the ADC driver\n");
> }
> #endif
> ...
>
Let's to ignore the fact you are violating the userspace/kernel layer.
Try to avoid doing it. Your application needs to use access the LEDs
using the USERLEDS support. There is an example to stm32f103-minimum
board.
> tm16_init is just bit bang, also LED_out(), which delivers data to the
> tm1653
> chip I'm using to drive the LEDs.
> config_init() tries to read json config file from NXFFS, which should have
> been
Instead using json, maybe you could use Inifile, please take a look on
FSUTILS_INIFILE. I think it will use less memory than JSON.
> mounted after boardctl.
> serial_init() is empty for later use.
> Up until sam_adc_setup gets called, /dev/null gets init, the via
> board_app_initialize() I mount procfs and my SPI flash.
> When sam_adc_setup() gets called somehow the inodes tables it searches in
> seem to be corrup, at least the result makes no sense for me, but I don't
> understand that code path and memory structures well enough yet.
> If I call sam_adc_setup() before boardctl() it does init, but fails to
> open later when I try to use it.
> Then I thought, lets reduce memory usage and don't mount the NXFFS for now.
> Without that (which also inits the SPI), it never returns from boardctl().
>
Try to use the Custom board late initialization, maybe it could help you.
Normally I prefer to do everything booting the NSH and calling my
application from its prompt, only when everything is working I change
the entry point to my application.
> I'm open for ideas.
> My current plan is to setup a Linux system and try plain NuttX on an
> Arduino Zero.
>
This should be a better idea because you will have 32KB of RAM. They
after getting it working you can remove not necessary features to
eventually get it working reliable on 16KB RAM.
In the past I got NuttX running on less than 2KB RAM, but it was a PoC
and all main subsystem were removed, including the VFS. It mean I was
violating the abstraction like you did! :-D
Look here: https://www.flickr.com/photos/79703543@N00/18013069041/sizes/h/
See the usage RAM from the 'free' command.
BR,
Alan