LWMesh: How to setup a standalone project

Go To Last Post
35 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've used the ASF demo applications to get some working application code.  Now I want this application code to run on a standalone stack.

I'm using a SAMD20 XPlained Pro board and a Wireless Xplained Pro Zigbit with the 212b.

 

 

I got pretty far and then ran into a roadblock so let me describe how far I got and what my thoughts are now.

 

--File->New Project->GCC C ASF Board Project, select the SAMD20 XPlained Pro board.

--I followed the instructions in the LWMesh getting started guide.  I included all the files in my project.  (this took way longer than it should have...)

--compiler gave me "file not found" errors so I added the /inc directories to the list of include paths.

--compiler said some stuff wasn't defined so I added the definitions HAL_ATSAMD20J18 and PHY_AT86RF212

 

Now, I'm stuck here:

 

Error    3    implicit declaration of function 'HAL_GPIO_PHY_CS_set' [-Werror=implicit-function-declaration]    C:\Users\ODI\Documents\Atmel Studio\6.2\GccBoardProject3\GccBoardProject3\src\LWMesh_standalone\hal\atsamd20\inc\halPhy.h    103    3    GccBoardProject3

 

The error is caused by this function:

INLINE void HAL_PhySpiDeselect(void)
{
  HAL_GPIO_PHY_CS_set();
}

 

Please correct me if I'm wrong here:

 HAL_GPIO_PHY_CS_set()  is a macro that is defined by another macro, eg. HAL_GPIO_PIN(PHY_CS,     A, 17);

 

 

The file that threw the error, halPhy.h, has this following snippet:

/*- Definitions ------------------------------------------------------------*/
#if defined(PLATFORM_XPLAINED_PRO_SAMD20_RZ600)
  // Rz600 radio module connected to EXT2[11:20]
  HAL_GPIO_PIN(PHY_RST,    A, 8);
  HAL_GPIO_PIN(PHY_IRQ,    B, 13);
  HAL_GPIO_PIN(PHY_SLP_TR, B, 12);
  HAL_GPIO_PIN(PHY_CS,     A, 17);
  HAL_GPIO_PIN(PHY_MISO,   A, 16);
  HAL_GPIO_PIN(PHY_MOSI,   A, 18);
  HAL_GPIO_PIN(PHY_SCK,    A, 19);
#elif defined(PLATFORM_XPLAINED_PRO_SAMD20_REB)
  // REBxxx-XPRO connected to EXT2
  HAL_GPIO_PIN(PHY_RST,    A, 22);
  HAL_GPIO_PIN(PHY_IRQ,    B, 14);
  HAL_GPIO_PIN(PHY_SLP_TR, B, 15);
  HAL_GPIO_PIN(PHY_CS,     A, 17);
  HAL_GPIO_PIN(PHY_MISO,   A, 16);
  HAL_GPIO_PIN(PHY_MOSI,   A, 18);
  HAL_GPIO_PIN(PHY_SCK,    A, 19);
#endif

 

What I'm thinking is, obviously, that since I am using neither the RZ600 nor the REB, the macros aren't defined for my radio board.

 

So I am just going to copy paste those HAL_GPIO_PIN statements and modify them according to the schematic of my Wireless Xplained Pro board.

 

 

What's really weird is, this information was already included in the ASF directory, at the time when I created the GCC C Board Project.

In the file ASF/sam0/samd20_xplained_pro.h , there is the following snippet:

 

#define AT86RFX_SPI                  EXT1_SPI_MODULE
#define AT86RFX_RST_PIN              EXT1_PIN_7
#define AT86RFX_MISC_PIN             EXT1_PIN_12
#define AT86RFX_IRQ_PIN              EXT1_PIN_9
#define AT86RFX_SLP_PIN              EXT1_PIN_10
#define AT86RFX_SPI_CS               EXT1_PIN_15
#define AT86RFX_SPI_MOSI             EXT1_PIN_16
#define AT86RFX_SPI_MISO             EXT1_PIN_17
#define AT86RFX_SPI_SCK              EXT1_PIN_18
#define AT86RFX_CSD                  EXT1_PIN_5
#define AT86RFX_CPS                  EXT1_PIN_8
#define LED0 LED0_PIN

 

where those symbols on the right are macros eg.    #define EXT1_PIN_7                PIN_PB02

and that's exactly what I need right?

 

 

Hope it will work... will share results.

 

 

Last Edited: Fri. Oct 16, 2015 - 12:25 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

If you just download standalone version, it will have projects already setup. You don't need to do anything extra.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

yep that's what I'm going to try next.  things just got weirder as I tried to get the project to compile.

 

I got SERCOM_SPI_CTRLA_DOPO undefined,

 

then a multiple reference to _exit(),

 

then I got undefined reference to _bss, _data, _edata, _stack_top, in this function.

 

void HAL_IrqHandlerReset(void)
{
  unsigned int *src, *dst;

  src = &_etext;
  dst = &_data;
  while (dst < &_edata)
    *dst++ = *src++;

  dst = &_bss;
  while (dst < &_ebss)
    *dst++ = 0;

  main();
  while (1);
}

 

....what?

 

ok let's just ignore the above and let me try using the given project files

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

....say it ain't so, Alex!!  I don't see a project file for SAMD20 and RF212

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

alright I'm stuck... here are the pin definitions, in case anyone has the power to help me out : )

looking for instructions for how to setup a working LWMesh application using SAMD20 XPlained Pro and Wireless XPlained Pro Zigbit w/ 212B

 

in the file halPhy.h

 

/*- Definitions ------------------------------------------------------------*/
#if defined(PLATFORM_XPLAINED_PRO_SAMD20_RZ600)
  // Rz600 radio module connected to EXT2[11:20]
  HAL_GPIO_PIN(PHY_RST,    A, 8);
  HAL_GPIO_PIN(PHY_IRQ,    B, 13);
  HAL_GPIO_PIN(PHY_SLP_TR, B, 12);
  HAL_GPIO_PIN(PHY_CS,     A, 17);
  HAL_GPIO_PIN(PHY_MISO,   A, 16);
  HAL_GPIO_PIN(PHY_MOSI,   A, 18);
  HAL_GPIO_PIN(PHY_SCK,    A, 19);
#elif defined(PLATFORM_XPLAINED_PRO_SAMD20_REB)
  // REBxxx-XPRO connected to EXT2
  HAL_GPIO_PIN(PHY_RST,    A, 22);
  HAL_GPIO_PIN(PHY_IRQ,    B, 14);
  HAL_GPIO_PIN(PHY_SLP_TR, B, 15);
  HAL_GPIO_PIN(PHY_CS,     A, 17);
  HAL_GPIO_PIN(PHY_MISO,   A, 16);
  HAL_GPIO_PIN(PHY_MOSI,   A, 18);
  HAL_GPIO_PIN(PHY_SCK,    A, 19);
#elif defined(PLATFORM_XPLAINED_PRO_SAMD20_212B) //steve added this
  // 212B-XPRO connected to EXT1
  HAL_GPIO_PIN(PHY_RST,    B, 2);
  HAL_GPIO_PIN(PHY_IRQ,    B, 4);
  HAL_GPIO_PIN(PHY_SLP_TR, B, 5);
  HAL_GPIO_PIN(PHY_CS,     A, 5);
  HAL_GPIO_PIN(PHY_MISO,   A, 4);
  HAL_GPIO_PIN(PHY_MOSI,   A, 6);
  HAL_GPIO_PIN(PHY_SCK,    A, 7);
#endif

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Give me some time, I'll make projects for you.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Here are the projects and Makefile for WSNDemo. No other changes to the source code are required. Connect your Xpro ZigBit extension board to EXT2 header and it all should work.

 

The way this project was obtained: I started with Makefile_XplainedPro_ATSAMD20_Rf233 projects and simply searched and replaced 233 with 212 everywhere using a text editor.

 

PS: Feel free to continue this discussion here or in private, whatever works for you.

Attachment(s): 

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

Last Edited: Wed. May 27, 2015 - 10:18 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That's exactly what I did, and I verified that the tranceiver is working by seeing that the PHY_Init() function didn't stall.

 

I started with Peer2Peer and tried to verify that the SYS_Timer works by setting up a 1 second timer, but it didn't.  Can't see any differences with the project file that you attached vs. what I did myself, but for some reason the SYS_Timer works with your project file so I guess I'll just start with that.

 

Thanks very much!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

steve_at_odi wrote:
a Wireless Xplained Pro Zigbit with the 212b.

Just out of interest, do you mean this:

 

AT86RF212B ZigBit Xplained PRO Extension

http://www.atmel.com/tools/ATZB-...

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Yes, this one. It is basically the only one that does not have an MCU in it.

 

The picture is generic. There is no programming header and buttons/LEDs on the real board, of course.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

Last Edited: Thu. May 28, 2015 - 06:20 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So similar to this one for the AT86RF233?

 

AT86RF233 REB Xplained Pro Extension

http://www.atmel.com/tools/ATREB...

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 2

REB boards are for plain transceivers, ZigBit extension boards are for modules. They have the same pinout.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

dang I still haven't succeeded in creating a project from scratch.

 

I created a "new GCC application" , thinking that I would avoid ASF and the associated complications.  But Atmel Studio asked me which chip I'm using, and when it created the project, it included a CMSIS directory.  I realized that the linker script in the CMSIS directory is not compatible with halStartup.c because _stack_top is not defined in the linker script.  see the snippet:

__attribute__ ((section(".vectors")))
void (* const vectors[])(void) =
{
  &_stack_top,                   // 0 - Initial Stack Pointer Value

...

 

So I used the linker script WSNDemo/linker/atsamd20j18.ld

 

 

and now I'm getting these totally unexpected linker errors:

undefined reference to 'PHY_DataReq'                          in nwkTx.c

undefined reference to 'PHY_Init'                                 in sys.c

undefined reference to 'PHY_TaskHandler'                    in sys.c

 

ever seen this before?  after removing all application code, these 3 PHY function calls are the only ones that cause problems.  If I comment the 3 out, the project builds.

it's weird because Atmel Studio is aware of these functions; I can goto implementation and find references...

 

Well I guess I'll just keep trying and learn a bit more each time...maybe once a day.

 

Do you guys use Atmel Studio at all...?

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

You don't need to create a project. You open a sample project (the one I've sent you) and add things to it as needed.

 

So the process step by step:

1. Download standalone SDK from here: http://www.atmel.com/tools/light...

2. Unpack it.

3. Unpack the project files I've attached a few messages back on top of the standalone version of the WSNDemo application.

4. Open solution apps\WSNDemo\astudio\XplainedPro_ATSAMD20_Rf212.atsln from AS.

5. At this point you should have application that compiles and works.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

yep I'm working with what you attached for developing the application code,

I just want to understand what's happening with the toolchain in case it becomes an issue later.  it's not a real issue yet.

 

 

Question:  are the files in hal/atsamd20/inc  part of ASF, part of LWMesh, or just something that Atmel gives to developers?  

 

 

Also, I think there's a typo, in hal/atsamd20/inc/ , samd20j18a.h should be just samd20j18.h  There is a yellow exclamation mark icon for samd20j18a.h.

does it make a difference?

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

steve_at_odi wrote:
I just want to understand what's happening with the toolchain in case it becomes an issue later.  it's not a real issue yet.
If you are starting with a new project, you are missing PHY functions because you have not set defines in the toolchain settings. This is most likely. If it is not the case, then I'll need complete projects to tell what is wrong with them.

 

steve_at_odi wrote:
Question:  are the files in hal/atsamd20/inc  part of ASF, part of LWMesh, or just something that Atmel gives to developers? 
They are distributed with ASF, but they are just generic header files that can be used for standalone projects as well.

 

steve_at_odi wrote:
Also, I think there's a typo, in hal/atsamd20/inc/ , samd20j18a.h should be just samd20j18.h  There is a yellow exclamation mark icon for samd20j18a.h.

does it make a difference?

Yes, it is a typo, but it does not make any difference. The important part is that all source code files are present, header files are there for completeness and convenience.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

this surprises me... searching for halstartup.c returns only 2 threads including this one.

 

Am I correct that you wrote the HAL .c and .h files that begin with "hal",  but all the other files in HAL, eg. core_cm0plus.h and component_adc.h are supplied by Atmel?

 

I'm trying to set up RTC w/ interrupt, by looking at how you set up the TC4 interrupt.  This will work, right?

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

steve_at_odi wrote:
this surprises me... searching for halstartup.c returns only 2 threads including this one.
Why is this suprprising?

 

steve_at_odi wrote:
Am I correct that you wrote the HAL .c and .h files that begin with "hal",  but all the other files in HAL, eg.
Correct.

 

steve_at_odi wrote:
core_cm0plus.h
Supplied by ARM.

 

steve_at_odi wrote:
and component_adc.h are supplied by Atmel?
Correct.

 

steve_at_odi wrote:
I'm trying to set up RTC w/ interrupt, by looking at how you set up the TC4 interrupt.  This will work, right?
Yes. You need to initialize RTC registers and define HAL_IrqHandlerRtc(). Your interrupt handler will substitute the default one, since it is marked as "weak". You don't need to change anything in halStartup.c.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

void HAL_IrqHandlerRtc(void)
{
    HAL_LedToggle(APP_LED_NETWORK);
    RTC->MODE1.INTFLAG.bit.OVF = 1; //clear the flag
}

/*************************************************************************//**
*****************************************************************************/

void RTC_Init(void)
{
    GCLK->CLKCTRL.reg = GCLK_CLKCTRL_ID(RTC_GCLK_ID) |
    GCLK_CLKCTRL_CLKEN | GCLK_CLKCTRL_GEN(2);                //hook up the GCLK
    
    RTC->MODE1.CTRL.bit.MODE = 1;                            //16-bit counter mode
    RTC->MODE1.CTRL.bit.PRESCALER = 16;                        //prescale the GCLK
    RTC->MODE1.PER.bit.PER = 10000;                    while(RTC->MODE1.STATUS.bit.SYNCBUSY == 1){;} //set period and sync
    RTC->MODE1.INTENSET.bit.OVF = 1;
    NVIC_EnableIRQ(RTC_IRQn);                                //enable interrupt
    RTC->MODE1.CTRL.bit.ENABLE = 1;                    while(RTC->MODE1.STATUS.bit.SYNCBUSY == 1){;}  //enable and sync
}

 

well here it is in case anyone wants it.  The RTC_Init() function is independent of LWMesh, but the IRQ handler is hooked up in a file called halStartup.c, in the LWMesh stack.

 

Am I missing something here?  why did I have to write this?  I should have had this exact 7 line snippet starting from day 1, and then all I'd have to do is simply look at the datasheet and replace the right hand sides of the equals signs with the appropriate values or symbols... what?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

You don't have this in LwMesh, because it is a wireless stack. There is also no ADC, PWM and any other drivers apart from a few needed by the sample application.

 

ASF has this, but in a much more convoluted way.

 

I agree that there should be a database of simple code snippets like this, but this is not a place to complain about it, no one will hear.

 

In any case, there will be a lot of code you will have to write, that's what software developers do.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OK, I wasn't trying to complain, just understand.  I guess I was spoiled at my last job where I used a TMS320.  TI provides headers and code for all the peripherals and initialization.  Didn't use a stack.  It was cool...

 

Thanks again for all the help!  

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

This is one of the most common complaints and I'm constantly pushing towards making simple register-level examples, but without a lot of success so far.

 

Also, to be fair D20 is way more complicated than TMS320. Building a library of code samples that will be useful for all cases will take some time and maintaining it afterwards is also going to be a nightmare.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I don't know where to post this question since it is about the SAMD20, but it is about sleep, which is probably relevant to people using LWMesh, right?

 

Topic:   Did I run into that errata where the NVM controller (flash) dies?

 

So I got the RTC working and interrupting, and then I figured I could try this to see if sleep happens:    (this is the main while(1) loop)

 

  while (1)
  {
    //SYS_TaskHandler();
    APP_TaskHandler();
    
    //go to sleep, get woken up by RTC interrupt
    SCB->SCR |= SCB_SCR_SLEEPDEEP_Msk;
    __WFI();
  }

 

The LED was toggling every few seconds which I expected, so I removed the current measurement header and plugged in an ammeter.  I got a constant 260uA, but I expected a pulsed current, not a constant.  (This really makes no sense because that LED has a 330 ohm resistor and the LED current has to go through that current measurement header/jumper right?  I should not be seeing a constant... crappy meter maybe?)  

 

So I figured I had to turn off some clocks and possibly set the IDLE bits to stop the CPU,AHB and APB clocks.

 

So I put the following in main(), just before the while(1)  :

 

  //PM->SLEEP.bit.IDLE = 0x2; //stop CPU, AHB and APB clocks
  //PM->AHBMASK.reg = 0;  //stop all clocks in this group
  //PM->APBAMASK.reg = 0; //stop all clocks
  //PM->APBAMASK.reg = 0x20;  //enable RTC clock, bit 5
  //PM->APBBMASK.reg = 0;

 

But after I flashed it, I am unable to flash it again.  Atmel Studio says:

 

Failed to launch program.

Error: Unexpected Chip Identifier 0x00000000 (expected 0x10001300)

 

 

 

Using another board works fine.  I have extra chips so I can replace the SAMD20.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I don't have a lot of experience with low power modes on those micros. But I don't think it is possible to kill the micro this way. Most likely MCU goes to sleep and it interferes with debugger's ability do program it.

 

I think chip erase should help. The same exact thing happened on AVRs all the time. The way to avoid this annoyance - put a 2-3 second active delay at the beginning of a program, this will let debugger start working with the chip before it goes to sleep.

 

Can you send a complete project, so I could try it on my side?

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

this is why I want to know how to create my own projects : )

 

I'll make a zip of the directory I'm working in and tell you the name of the project file I'm using... just a minute

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

I still don't get why you need to create your own projects. You are the first one who wants to do that.

 

All I need is a full archive of everything you are currently working with.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The project file is called XplainedPro_ATSAMD20_Rf212 .

it is in the WSNDemo folder (in apps)

 

Just scroll down to the bottom of WSNDemo.c to see the relevant stuff.

 

With the commented lines commented, you should see the LED blink roughly every 2 seconds.  I don't know exactly how fast to expect, I just fiddled with the RTC prescaler and period until I got a human detectable period.

 

Then try uncommenting those lines that start with PM->   or __WFI();

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Also, as a sanity check, can you try to measure the current using that header?

 

I'm getting a constant 260uA, even with the Fluke 87 now.  It has a bargraph which I don't see pulsing at all like it should.  This is regardless of sleep... I should be seeing atleast 1mA when the LED is on right?

 

Page 1 of the SAMD20 XPlained Pro schematic is just the power supplies and it looks like they all "meet together" at that current measurement header.

I just took 2 AA batteries and connected them to VCC and GND of that 4-pin PWR header.

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

So you don't see LED blinking because you powered down the APB bus attached to that GPIO controller.

 

To recover from that locked state, open Device Programming dialog, select your board, and click "Apply". Then without reading the device signature (which will fail), go to the Memories tab and click "Erase Now" button ("Erase Chip" must be selected in the drop down menu).

 

Also, PRESCALER is 4 bits, so the value 16 will be truncated to 0. Compiler complains about that.

 

I'll play with current measurement tomorrow.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Here is a project that gets 3.5 uA (there are some fluctuations, I believe they are caused by EDBG still attached to the target).

 

I've removed all extra stuff, but all my changes are in WSNDemo.c, so you can just take this file to your project.

 

Also note that LED current is not measured though the current sense connector, since LED is connected directly to VCC_TARGET_P3V3 and current sense only measures VCC_MCU_P3V3.

 

But you can see spikes of current when MCU wakes up. I also toggle PA2 on each wakeup and right now it toggles every 8 seconds.

 

For some reason prescaler in RTC does not prescale anything, so I'm prescaling the RTC clock though GENDIV.  I'll look at that later.

 

I'm now trying to figure out a cleaner board with no extra components on it to do better power measurement, but the ballpark is there.

Attachment(s): 

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank you... so much!!

 

I've been trying to get sleep to work, but now I'm stuck at 20mA, not even 250uA.  Will look at your project immediately.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ok that was stupid, I accidentally shorted 2 pins when I replaced the SAMD20 chip on one of my boards yesterday.  Removed the short and...

 

Yep, 3.5uA, very good.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

I ran the same application on a simple board with nothing but the chip on it. The RTC was running from OSCULP32K (embedded ultra low power RC oscillator), since there is no external crystal. The IC was SAMD20G14 (16 KB flash, 2 KB RAM), since this is what I have as loose chips at the moment, but that should not make any difference.

 

I get stable 1.9 uA. This is probably as low as it will go.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for that figure.

 

Going back to the topic of this thread here... Is it possible to use ASF at all using the (standalone LWMesh) project you attached?

 

If I open that project and open ASF wizard, select the SAMD20 XPlained Pro, then it shows me a list of about 100 added files or toolchain configuration changes.  I click Finish.

Now there are the 3 default modules on the right side of ASF wizard:  Generic board support, PORT, SYSTEM.

 

And now the project doesn't compile, saying " hal.h: No such file or directory "

 

Do you think this is fixable with modifications to the compiler's list of search paths?

 

It'd be nice if I could still use the I2C and GPIO code that I've written using ASF.  it's not a huge difference though...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

I have no idea.  If you want to use ASF, it is probably better to start with ASF projects and add LwMesh files there and transfer corresponding defines and include paths in toolchain settings. Or just go with LwMesh from ASF and figure out how to make that work. With ASF you will have a lot of figuring out to do, so that's not going to be the hardest part.

NOTE: I no longer actively read this forum. Please ask your question on www.eevblog.com/forum if you want my answer.