Date   

Re: [Zephyr-devil] Tiny tile Zephyr implementation

Li, Jun R
 

 

Please try “make BOARD=tinytile”. The board name should be exactly same as “boards/x86/tinytile”.

 

From: <zephyr-devel-bounces@...> on behalf of Jie Zhou <zhoujie@...>
Date: Friday, October 13, 2017 at 01:16
To: Graham Stott <gbcstott1@...>, "zephyr-devel@..." <zephyr-devel@...>
Subject: Re: [Zephyr-devel] [Zephyr-devil] Tiny tile Zephyr implementation

 

Hey Graham,

 

Thanks for the help! It worked. To flash on tinyTILE, do make BOARD=arduino_101 flash. Since they are using the same Intel curie chip, it will work. Interesting that BOARD=tinyTILE doesn't work, maybe someone should look into that.

 

Sincerely,

Jie

 

On Wed, Oct 11, 2017 at 7:16 PM, Jie Zhou <zhoujie@...> wrote:

Hi Graham,

 

Hmm interesting, which CONFIG settings? Also I want to use tinyTILE for a bluetooth application that I am working on. I need tinyTILE for its wearable size. For flashing on to tinyTILE, all of the bluetooth sample examples provided by zephyr does the same thing; application flashes fine, but when I open minicom to view the outputs, minicom freezes. This holds true for even Hello World the last time I ran that. If you ever get around testing with the curieNano let me know.

 

Thanks,

Jie

 

On Wed, Oct 11, 2017 at 7:07 PM, Graham Stott <gbcstott1@...> wrote:

Jie,

 

My board is in use at this time so I cannot do this test for you. However I did look at  the Bluetooth beacon sample and I see that it is setting some Bluetooth related CONFIG  settings that are not tested in the BOARD=tileTile make. They are tested  in the arduino_101 make. I suggest you do a make of the Bluetooth beacon sample using BOARD=Arduino_101 and see if that helps.

 

Graham

 

From: Jie Zhou [mailto:zhoujie@...]
Sent: Wednesday, October 11, 2017 6:09 PM


To: Graham Stott <gbcstott1@...>
Cc: zephyr-devel@...
Subject: Re: [Zephyr-devil] Tiny tile Zephyr implementation

 

Hi Graham,

 

Could you flash the beacon example in zephyr? The path is samples/bluetooth/beacon. You might have to flash the hci_uart example, which is also in the bluetooth sample directory, to update the firmware. If you can do that and open minicom and see the outputs then we might be in luck and will switch over to the curienano.

 

Thank you very much,

Jie 

 

On Wed, Oct 11, 2017 at 2:36 PM, Graham Stott <gbcstott1@...> wrote:

Jie,

 

I do not have the TinyTile board so I cannot try flashing it. However I do have the DFRobot CurieNano which is a similar board. I have no problem flashing this board. I used the instructions (DFU) for Arduino 101.

 

Graham

 

From: Jie Zhou [mailto:zhoujie@...]
Sent: Wednesday, October 11, 2017 3:11 PM
To: Graham Stott <gbcstott1@...>
Cc: zephyr-devel@...
Subject: Re: [Zephyr-devil] Tiny tile Zephyr implementation

 

Hi Graham,

Thanks for responding! About the similarities of TinyTILE and Arduino101, although the chip is the same, we have been trying to flash applications to tinyTILE for a while now. The arduino can be flash with DFU using the FTDI cable, but tinyTILE doesn't respond to minicom after flashing. We have some inconsistent success with flashing tinyTILE via Flyswatter and settling the port to ttyACM0. Either there is some issues with tinyTILE support from zephyr or the protocol of the chip is different than Arduino.

 

Thanks,

Jie

 

On Tue, Oct 10, 2017 at 12:29 PM, Graham Stott <gbcstott1@...> wrote:

I meant to also say to look at projects for Arduino/Genuine 101 as tiny Tile is a scaled down version of this board.

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Graham Stott
Sent: Tuesday, October 10, 2017 2:01 PM
To: 'Jie Zhou' <zhoujie@...>; zephyr-devel@...
Subject: Re: [Zephyr-devel] Tinytile Zephyr implementation

 

As tinyTile is basically just a version of the Intel® Curie™ module, you can look for projects under Curie. Yes. It has additional pins but the rest is the same

 

Graham

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Jie Zhou
Sent: Tuesday, October 10, 2017 1:21 AM
To: zephyr-devel@...
Subject: [Zephyr-devel] Tinytile Zephyr implementation

 

Hi All,

 

Has anyone done anything with tinyTILE? Since the board is quite new I was wondering if someone has done a project with Zephyr OS on tinyTILE. The specs of the chip looks promising for IoT implementations. Any info or the setup you are using will help. I'm trying to evaluate the capability of tinyTILE with Zephyr.

 

Thanks,

Jie

 

 

 

 


New flashing scripts merged, please report any issues

Marti Bolivar <marti.bolivar@...>
 

Hi,

Last night, a pull request of mine was merged which uses a Python script to flash binaries ("make flash"):


If you run into any problems, you can fall back on the shell scripts by setting USE_ZEPHYR_FLASH_DEBUG_SHELL in your environment for now:

export USE_ZEPHYR_FLASH_DEBUG_SHELL=1

I'd really appreciate reports of any issues you may find. I tested on all the boards I have, but I wasn't able to test everything.

In your report, please include the output of this command, run from samples/hello_world:

KBUILD_VERBOSE=1 BOARD=your_board make flash

Known issues (and proposed fixes) for  quark_se_c1000_devboard and arduino_101 are tracked in:


Thanks,
Marti
 


Re: [Zephyr-devil] Tiny tile Zephyr implementation - Needs fixing

Graham Stott <gbcstott1@...>
 

Jie,

 

Great.  I believe that cleaning up the CONFIG setting would fix the tinyTile build.

 

Graham

 

From: Jie Zhou [mailto:zhoujie@...]
Sent: Friday, October 13, 2017 1:16 AM
To: Graham Stott <gbcstott1@...>; zephyr-devel@...
Subject: Re: [Zephyr-devil] Tiny tile Zephyr implementation

 

Hey Graham,

 

Thanks for the help! It worked. To flash on tinyTILE, do make BOARD=arduino_101 flash. Since they are using the same Intel curie chip, it will work. Interesting that BOARD=tinyTILE doesn't work, maybe someone should look into that.

 

Sincerely,

Jie

 

On Wed, Oct 11, 2017 at 7:16 PM, Jie Zhou <zhoujie@...> wrote:

Hi Graham,

 

Hmm interesting, which CONFIG settings? Also I want to use tinyTILE for a bluetooth application that I am working on. I need tinyTILE for its wearable size. For flashing on to tinyTILE, all of the bluetooth sample examples provided by zephyr does the same thing; application flashes fine, but when I open minicom to view the outputs, minicom freezes. This holds true for even Hello World the last time I ran that. If you ever get around testing with the curieNano let me know.

 

Thanks,

Jie

 

On Wed, Oct 11, 2017 at 7:07 PM, Graham Stott <gbcstott1@...> wrote:

Jie,

 

My board is in use at this time so I cannot do this test for you. However I did look at  the Bluetooth beacon sample and I see that it is setting some Bluetooth related CONFIG  settings that are not tested in the BOARD=tileTile make. They are tested  in the arduino_101 make. I suggest you do a make of the Bluetooth beacon sample using BOARD=Arduino_101 and see if that helps.

 

Graham

 

From: Jie Zhou [mailto:zhoujie@...]
Sent: Wednesday, October 11, 2017 6:09 PM


To: Graham Stott <gbcstott1@...>
Cc: zephyr-devel@...
Subject: Re: [Zephyr-devil] Tiny tile Zephyr implementation

 

Hi Graham,

 

Could you flash the beacon example in zephyr? The path is samples/bluetooth/beacon. You might have to flash the hci_uart example, which is also in the bluetooth sample directory, to update the firmware. If you can do that and open minicom and see the outputs then we might be in luck and will switch over to the curienano.

 

Thank you very much,

Jie 

 

On Wed, Oct 11, 2017 at 2:36 PM, Graham Stott <gbcstott1@...> wrote:

Jie,

 

I do not have the TinyTile board so I cannot try flashing it. However I do have the DFRobot CurieNano which is a similar board. I have no problem flashing this board. I used the instructions (DFU) for Arduino 101.

 

Graham

 

From: Jie Zhou [mailto:zhoujie@...]
Sent: Wednesday, October 11, 2017 3:11 PM
To: Graham Stott <gbcstott1@...>
Cc: zephyr-devel@...
Subject: Re: [Zephyr-devil] Tiny tile Zephyr implementation

 

Hi Graham,

Thanks for responding! About the similarities of TinyTILE and Arduino101, although the chip is the same, we have been trying to flash applications to tinyTILE for a while now. The arduino can be flash with DFU using the FTDI cable, but tinyTILE doesn't respond to minicom after flashing. We have some inconsistent success with flashing tinyTILE via Flyswatter and settling the port to ttyACM0. Either there is some issues with tinyTILE support from zephyr or the protocol of the chip is different than Arduino.

 

Thanks,

Jie

 

On Tue, Oct 10, 2017 at 12:29 PM, Graham Stott <gbcstott1@...> wrote:

I meant to also say to look at projects for Arduino/Genuine 101 as tiny Tile is a scaled down version of this board.

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Graham Stott
Sent: Tuesday, October 10, 2017 2:01 PM
To: 'Jie Zhou' <zhoujie@...>; zephyr-devel@...
Subject: Re: [Zephyr-devel] Tinytile Zephyr implementation

 

As tinyTile is basically just a version of the Intel® Curie™ module, you can look for projects under Curie. Yes. It has additional pins but the rest is the same

 

Graham

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Jie Zhou
Sent: Tuesday, October 10, 2017 1:21 AM
To: zephyr-devel@...
Subject: [Zephyr-devel] Tinytile Zephyr implementation

 

Hi All,

 

Has anyone done anything with tinyTILE? Since the board is quite new I was wondering if someone has done a project with Zephyr OS on tinyTILE. The specs of the chip looks promising for IoT implementations. Any info or the setup you are using will help. I'm trying to evaluate the capability of tinyTILE with Zephyr.

 

Thanks,

Jie

 

 

 

 


Re: [Zephyr-devil] Tiny tile Zephyr implementation

Jie Zhou <zhoujie@...>
 

Hey Graham,

Thanks for the help! It worked. To flash on tinyTILE, do make BOARD=arduino_101 flash. Since they are using the same Intel curie chip, it will work. Interesting that BOARD=tinyTILE doesn't work, maybe someone should look into that.

Sincerely,
Jie

On Wed, Oct 11, 2017 at 7:16 PM, Jie Zhou <zhoujie@...> wrote:
Hi Graham,

Hmm interesting, which CONFIG settings? Also I want to use tinyTILE for a bluetooth application that I am working on. I need tinyTILE for its wearable size. For flashing on to tinyTILE, all of the bluetooth sample examples provided by zephyr does the same thing; application flashes fine, but when I open minicom to view the outputs, minicom freezes. This holds true for even Hello World the last time I ran that. If you ever get around testing with the curieNano let me know.

Thanks,
Jie

On Wed, Oct 11, 2017 at 7:07 PM, Graham Stott <gbcstott1@...> wrote:

Jie,

 

My board is in use at this time so I cannot do this test for you. However I did look at  the Bluetooth beacon sample and I see that it is setting some Bluetooth related CONFIG  settings that are not tested in the BOARD=tileTile make. They are tested  in the arduino_101 make. I suggest you do a make of the Bluetooth beacon sample using BOARD=Arduino_101 and see if that helps.

 

Graham

 

From: Jie Zhou [mailto:zhoujie@...]
Sent: Wednesday, October 11, 2017 6:09 PM


To: Graham Stott <gbcstott1@...>
Cc: zephyr-devel@...ct.org
Subject: Re: [Zephyr-devil] Tiny tile Zephyr implementation

 

Hi Graham,

 

Could you flash the beacon example in zephyr? The path is samples/bluetooth/beacon. You might have to flash the hci_uart example, which is also in the bluetooth sample directory, to update the firmware. If you can do that and open minicom and see the outputs then we might be in luck and will switch over to the curienano.

 

Thank you very much,

Jie 

 

On Wed, Oct 11, 2017 at 2:36 PM, Graham Stott <gbcstott1@...> wrote:

Jie,

 

I do not have the TinyTile board so I cannot try flashing it. However I do have the DFRobot CurieNano which is a similar board. I have no problem flashing this board. I used the instructions (DFU) for Arduino 101.

 

Graham

 

From: Jie Zhou [mailto:zhoujie@...]
Sent: Wednesday, October 11, 2017 3:11 PM
To: Graham Stott <gbcstott1@...>
Cc: zephyr-devel@...ct.org
Subject: Re: [Zephyr-devil] Tiny tile Zephyr implementation

 

Hi Graham,

Thanks for responding! About the similarities of TinyTILE and Arduino101, although the chip is the same, we have been trying to flash applications to tinyTILE for a while now. The arduino can be flash with DFU using the FTDI cable, but tinyTILE doesn't respond to minicom after flashing. We have some inconsistent success with flashing tinyTILE via Flyswatter and settling the port to ttyACM0. Either there is some issues with tinyTILE support from zephyr or the protocol of the chip is different than Arduino.

 

Thanks,

Jie

 

On Tue, Oct 10, 2017 at 12:29 PM, Graham Stott <gbcstott1@...> wrote:

I meant to also say to look at projects for Arduino/Genuine 101 as tiny Tile is a scaled down version of this board.

 

From: zephyr-devel-bounces@...hyrproject.org [mailto:zephyr-devel-bounces@lists.zephyrproject.org] On Behalf Of Graham Stott
Sent: Tuesday, October 10, 2017 2:01 PM
To: 'Jie Zhou' <zhoujie@...>; zephyr-devel@...ct.org
Subject: Re: [Zephyr-devel] Tinytile Zephyr implementation

 

As tinyTile is basically just a version of the Intel® Curie™ module, you can look for projects under Curie. Yes. It has additional pins but the rest is the same

 

Graham

 

From: zephyr-devel-bounces@...hyrproject.org [mailto:zephyr-devel-bounces@lists.zephyrproject.org] On Behalf Of Jie Zhou
Sent: Tuesday, October 10, 2017 1:21 AM
To: zephyr-devel@...ct.org
Subject: [Zephyr-devel] Tinytile Zephyr implementation

 

Hi All,

 

Has anyone done anything with tinyTILE? Since the board is quite new I was wondering if someone has done a project with Zephyr OS on tinyTILE. The specs of the chip looks promising for IoT implementations. Any info or the setup you are using will help. I'm trying to evaluate the capability of tinyTILE with Zephyr.

 

Thanks,

Jie

 

 




Debugging __reset?

David Leach
 

I find myself in a situation where my platform keeps going through the __reset and I’m not sure why?

 

How does one debug something like this with Zephyr? My target is a FRDM-KW41Z board.

 

David

 

David Leach

 

NXP Semiconductors

phone: +1.210.241.6761

Email: david.leach@...

 

 

** PROPRIETARY & COMPANY-CONFIDENTIAL **

 


Zephyr 1.9.1 released

Nashif, Anas
 

Hi,

First bug fix release for 1.9 with many Bluetooth related bug fixes, see the release page for details:

 

              https://github.com/zephyrproject-rtos/zephyr/releases/tag/zephyr-v1.9.1

 

Thanks,

 

Anas

 


Zephyr SDK 0.9.2-rc5

Nashif, Anas
 

Hi,

 

RC5 has been released and available from https://github.com/zephyrproject-rtos/meta-zephyr-sdk/releases/tag/0.9.2-rc5

 

This release removes the QEMU update and restores the original versions available in current SDK due to some issues discovered on multiple architectures that will be fixed in another release.

 

This will hopefully be the last RC before the final release.

 

Regards,

Anas


Re: I2C for STM32F3

Yannis Damigos
 

On 10/12/2017 07:37 PM, Yannis Damigos wrote:
Thanks Erwan,

It works now. I will create a PR for it

Yannis

On 10/12/2017 06:25 PM, Erwan Gouriou wrote:
Hi,

I don't have time to test this yet, but looking into STM32F303 reference manual,
it seems that I2C on F3 is clock independent and hence, we should sepcify clock
before using it.
It seems this case is particular to F3 (at least F303).

Can you have a try defining clock with fowlloing LL function?
 //* Set I2C2 clock source as SYSCLK */
  LL_RCC_SetI2CClockSource(uint32_t I2CxSource);/
/With //I2CxSource:/
  *         @arg @ref LL_RCC_I2C1_CLKSOURCE_HSI
  *         @arg @ref LL_RCC_I2C1_CLKSOURCE_SYSCLK
  *         @arg @ref LL_RCC_I2C2_CLKSOURCE_HSI (*)
  *         @arg @ref LL_RCC_I2C2_CLKSOURCE_SYSCLK (*)
  *         @arg @ref LL_RCC_I2C3_CLKSOURCE_HSI (*)
  *         @arg @ref LL_RCC_I2C3_CLKSOURCE_SYSCLK (*)

Erwan


On 12 October 2017 at 15:47, Yannis Damigos <giannis.damigos@gmail.com <mailto:giannis.damigos@gmail.com>> wrote:



On Thu, Oct 12, 2017 at 3:52 PM, Wagenknecht, Daniel <Daniel.Wagenknecht@clage.de <mailto:Daniel.Wagenknecht@clage.de>> wrote:

Hi,____

__ __

I’m working on a project that needs I2C functionality on a STM32F0 Chip. Since STM32F0 support is not yet merged into zephyr (I’m observing https://github.com/zephyrproject-rtos/zephyr/pull/4260 <https://github.com/zephyrproject-rtos/zephyr/pull/4260>), I started working with a stm32f3_disco board, which I had available and which uses the same I2C driver (stm32-i2c-v2), with only minor differences (F0 has a combined Event/Error Interrupt, F3 splits both up). I also took a look at the disco_l475_iot1 board for inspiration, because I2C support in Zephyr for this board is implemented and it uses the stm32-i2c-v2 driver as well, but I don’t have one of those boards to test with.____

__ __

Just a little note before I explain the issues I’m running into on the stm32f3_disco: I basically did the same steps on stm32f4_disco board (which uses the stm32-i2c-v1 I2C driver) and got the  I2C bus working there. ____

I’m confident, that the basic procedure for adding I2C support to a STM32Fx based board is OK, since I got it working on the stm32f4_disco board this way.____

__ __

Back to stm32f3_disco. See attachment for the changes I did to the repo based on zephyr-v1.9.0 release.____

I’ve got it compiling with samples/drivers/i2c_fujitsu_fram example with a minor change and an I2C dummy device that acts like the fujitsu-fram (test-setup worked well with stm32f4_disco).____

__ __

diff --git a/samples/drivers/i2c_fujitsu_fram/src/main.c b/samples/drivers/i2c_fujitsu_fram/src/main.c____

__ __

@@ -13,5 +13,1 @@____

-#if defined(CONFIG_SOC_QUARK_SE_C1000_SS)____

-#define I2C_DEV CONFIG_I2C_SS_0_NAME____

-#else____

-#define I2C_DEV CONFIG_I2C_0_NAME____

-#endif____

+#define I2C_DEV "I2C_1"____

__ __

After flashing it onto the stm32f3_disco board the I2C Pins (PB8, PB9) are high with pull-up (like intended), but nothing is happening on the bus. When I single step through  the code with the debugger I loose connection in ____

file drivers/i2c/i2c_ll_stm32_v2.c____

function  msg_init(…)____

line 41____

__ __

Last step I can do is out of the LL_I2C_SetSlaveAddr(..) function. The debugger fails with the following message:____

__ __

Error: jtag status contains invalid mode value - communication failure____

Polling target stm32f3x.cpu failed, trying to reexamine____

Examination failed, GDB will be halted. Polling again in 100ms____

__ __

To reconnect to the board afterwards I need to disconnect it first, reset doesn’t help.____

__ __

So if you know of any changes I missed or did wrong, or are familiar with this type of gdb-errors, please help me out here.____

__ __

Sincerely____

__ __

*Daniel Wagenknecht**____*

Softwaredeveloper, R&D____

__ __

cid:C4FAA595-4AD0-4C9D-A648-5756BE9EA618____

__ __

*CLAGE GmbH*____

Pirolweg 1-5____

21337 Lüneburg | Germany____

__ __

Fon: +49 4131 8901-7906 <tel:+49%204131%2089017906>____

Fax: +49 4131 83200 <tel:+49%204131%2083200>____

E-Mail: daniel.wagenknecht@clage.de <mailto:daniel.wagenknecht@clage.de>____

www.clage.de <http://www.clage.de>____

__ __

__ __

__ __

__ __

__ __


_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org <mailto:Zephyr-devel@lists.zephyrproject.org>
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel>


Hi Daniel,

I was trying to get I2C working on stm32f3_disco a couple of months ago. You could find my local branch here https://github.com/ydamigos/zephyr/tree/f3disco <https://github.com/ydamigos/zephyr/tree/f3disco> (it needs a rebase to the master branch).
It just hangs after the line 41 of i2c_ll_stm32_v2.c like yours. It does not output any SYS_LOG on console. Below are the information I managed to collect.

Best regards,
Yannis

openocd debugserver output:
Info : halted: PC: 0x08000b98
Info : halted: PC: 0x08000afc
Info : halted: PC: 0x00000000

gdb output
(gdb) next
41              LL_I2C_SetTransferRequest(i2c, transfer);
(gdb) next
0x00000000 in ?? ()
(gdb) bt --full
No symbol "full" in current context.
(gdb) bt full
#0  0x00000000 in ?? ()
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) info frame
Stack level 0, frame at 0x0:
 pc = 0x0; saved pc = <unavailable>
 Outermost frame: previous frame identical to this frame (corrupt stack?)
 Arglist at unknown address.
 Locals at unknown address, Previous frame's sp is 0x0
(gdb) info registers
r0             0x0      0
r1             0x0      0
r2             0x0      0
r3             0x0      0
r4             0x0      0
r5             0x0      0
r6             0x0      0
r7             0x0      0
r8             0x0      0
r9             0x0      0
r10            0x0      0
r11            0x0      0
r12            0x0      0
sp             0x0      0x0
lr             0x0      0
pc             0x0      0x0
xPSR           0x0      0

_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org <mailto:Zephyr-devel@lists.zephyrproject.org>
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel>


Re: I2C for STM32F3

Yannis Damigos
 

Thanks Erwan,

It works now. I will create a PR for it

Yannis

On 10/12/2017 06:25 PM, Erwan Gouriou wrote:
Hi,

I don't have time to test this yet, but looking into STM32F303 reference manual,
it seems that I2C on F3 is clock independent and hence, we should sepcify clock
before using it.
It seems this case is particular to F3 (at least F303).

Can you have a try defining clock with fowlloing LL function?
 //* Set I2C2 clock source as SYSCLK */
  LL_RCC_SetI2CClockSource(uint32_t I2CxSource);/
/With //I2CxSource:/
  *         @arg @ref LL_RCC_I2C1_CLKSOURCE_HSI
  *         @arg @ref LL_RCC_I2C1_CLKSOURCE_SYSCLK
  *         @arg @ref LL_RCC_I2C2_CLKSOURCE_HSI (*)
  *         @arg @ref LL_RCC_I2C2_CLKSOURCE_SYSCLK (*)
  *         @arg @ref LL_RCC_I2C3_CLKSOURCE_HSI (*)
  *         @arg @ref LL_RCC_I2C3_CLKSOURCE_SYSCLK (*)

Erwan


On 12 October 2017 at 15:47, Yannis Damigos <giannis.damigos@gmail.com <mailto:giannis.damigos@gmail.com>> wrote:



On Thu, Oct 12, 2017 at 3:52 PM, Wagenknecht, Daniel <Daniel.Wagenknecht@clage.de <mailto:Daniel.Wagenknecht@clage.de>> wrote:

Hi,____

__ __

I’m working on a project that needs I2C functionality on a STM32F0 Chip. Since STM32F0 support is not yet merged into zephyr (I’m observing https://github.com/zephyrproject-rtos/zephyr/pull/4260 <https://github.com/zephyrproject-rtos/zephyr/pull/4260>), I started working with a stm32f3_disco board, which I had available and which uses the same I2C driver (stm32-i2c-v2), with only minor differences (F0 has a combined Event/Error Interrupt, F3 splits both up). I also took a look at the disco_l475_iot1 board for inspiration, because I2C support in Zephyr for this board is implemented and it uses the stm32-i2c-v2 driver as well, but I don’t have one of those boards to test with.____

__ __

Just a little note before I explain the issues I’m running into on the stm32f3_disco: I basically did the same steps on stm32f4_disco board (which uses the stm32-i2c-v1 I2C driver) and got the  I2C bus working there. ____

I’m confident, that the basic procedure for adding I2C support to a STM32Fx based board is OK, since I got it working on the stm32f4_disco board this way.____

__ __

Back to stm32f3_disco. See attachment for the changes I did to the repo based on zephyr-v1.9.0 release.____

I’ve got it compiling with samples/drivers/i2c_fujitsu_fram example with a minor change and an I2C dummy device that acts like the fujitsu-fram (test-setup worked well with stm32f4_disco).____

__ __

diff --git a/samples/drivers/i2c_fujitsu_fram/src/main.c b/samples/drivers/i2c_fujitsu_fram/src/main.c____

__ __

@@ -13,5 +13,1 @@____

-#if defined(CONFIG_SOC_QUARK_SE_C1000_SS)____

-#define I2C_DEV CONFIG_I2C_SS_0_NAME____

-#else____

-#define I2C_DEV CONFIG_I2C_0_NAME____

-#endif____

+#define I2C_DEV "I2C_1"____

__ __

After flashing it onto the stm32f3_disco board the I2C Pins (PB8, PB9) are high with pull-up (like intended), but nothing is happening on the bus. When I single step through  the code with the debugger I loose connection in ____

file drivers/i2c/i2c_ll_stm32_v2.c____

function  msg_init(…)____

line 41____

__ __

Last step I can do is out of the LL_I2C_SetSlaveAddr(..) function. The debugger fails with the following message:____

__ __

Error: jtag status contains invalid mode value - communication failure____

Polling target stm32f3x.cpu failed, trying to reexamine____

Examination failed, GDB will be halted. Polling again in 100ms____

__ __

To reconnect to the board afterwards I need to disconnect it first, reset doesn’t help.____

__ __

So if you know of any changes I missed or did wrong, or are familiar with this type of gdb-errors, please help me out here.____

__ __

Sincerely____

__ __

*Daniel Wagenknecht**____*

Softwaredeveloper, R&D____

__ __

cid:C4FAA595-4AD0-4C9D-A648-5756BE9EA618____

__ __

*CLAGE GmbH*____

Pirolweg 1-5____

21337 Lüneburg | Germany____

__ __

Fon: +49 4131 8901-7906 <tel:+49%204131%2089017906>____

Fax: +49 4131 83200 <tel:+49%204131%2083200>____

E-Mail: daniel.wagenknecht@clage.de <mailto:daniel.wagenknecht@clage.de>____

www.clage.de <http://www.clage.de>____

__ __

__ __

__ __

__ __

__ __


_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org <mailto:Zephyr-devel@lists.zephyrproject.org>
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel>


Hi Daniel,

I was trying to get I2C working on stm32f3_disco a couple of months ago. You could find my local branch here https://github.com/ydamigos/zephyr/tree/f3disco <https://github.com/ydamigos/zephyr/tree/f3disco> (it needs a rebase to the master branch).
It just hangs after the line 41 of i2c_ll_stm32_v2.c like yours. It does not output any SYS_LOG on console. Below are the information I managed to collect.

Best regards,
Yannis

openocd debugserver output:
Info : halted: PC: 0x08000b98
Info : halted: PC: 0x08000afc
Info : halted: PC: 0x00000000

gdb output
(gdb) next
41              LL_I2C_SetTransferRequest(i2c, transfer);
(gdb) next
0x00000000 in ?? ()
(gdb) bt --full
No symbol "full" in current context.
(gdb) bt full
#0  0x00000000 in ?? ()
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) info frame
Stack level 0, frame at 0x0:
 pc = 0x0; saved pc = <unavailable>
 Outermost frame: previous frame identical to this frame (corrupt stack?)
 Arglist at unknown address.
 Locals at unknown address, Previous frame's sp is 0x0
(gdb) info registers
r0             0x0      0
r1             0x0      0
r2             0x0      0
r3             0x0      0
r4             0x0      0
r5             0x0      0
r6             0x0      0
r7             0x0      0
r8             0x0      0
r9             0x0      0
r10            0x0      0
r11            0x0      0
r12            0x0      0
sp             0x0      0x0
lr             0x0      0
pc             0x0      0x0
xPSR           0x0      0

_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org <mailto:Zephyr-devel@lists.zephyrproject.org>
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel <https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel>


Re: stm32f4_disco issues

Pushpal Sidhu
 

Hello Erwan,

Thanks for the help; the CONFIG_GPIO_STM32_PORTD was missing. I'll
send a PR to add this to stm32f4_disco_defconfig later today.

Regarding debugging, I was using debug before, but was running into
the same thing. I think it was purely because Zephyr itself was hung.

I can now use debug, but am still going to use debugserver so I can
use external tools. FWIW, I have the STLink/V2, so the initial config
worked for me.

Thanks again,
- Pushpal

On Thu, Oct 12, 2017 at 4:33 AM, Erwan Gouriou <erwan.gouriou@linaro.org> wrote:
Hi Pushpal,


Regarding the blinky issue. It's happening since CONFIG_GPIO_STM32_PORTD is
not activated.
You should add it in board defconfig.

Then, regarding the debug issue.
Have you tried make BOARD=stm32f4_disco debug ?
This should be working.

Just take care that you might have some dependency depending on the STLINK
firmware on your board.
Current openocd support in zephyr for this board should only work on
STLINK-V2.

On my side, I have a STLINK-V2.1 firmware and I had to do some changes to
get it working:
In
zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/share/openocd/scripts/board/stm32f4discovery.cfg
+source [find interface/stlink-v2-1.cfg]
-source [find interface/stlink-v2.cfg]
But then, worked directly.

HIH

Erwan


On 11 October 2017 at 23:38, Pushpal Sidhu <psidhu.devel@gmail.com> wrote:

Hi All,

I'm attempting to flash the samples/basic/blinky/ project on the
stm32f4_disco board, but am running into issues.

Here's a list of steps I run through:
make BOARD=stm32f4_disco -C samples/basic/blinky/
make BOARD=stm32f4_disco -C samples/basic/blinky/ flash

Then nothing happens on board (no LED blink after power cycle). I
attempt to debug
make BOARD=stm32f4_disco -C samples/basic/blinky/ debugserver
gdb -tui -ex "target remote :3333" ../outdir/stm32f4_disco/zephyr.elf

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ../outdir/stm32f4_disco/zephyr.elf...done.
Remote debugging using :3333
warning: Architecture rejected target-supplied description
warning: Cannot convert floating-point register value to
non-floating-point type.
value has been optimized out
0x00000000 in ?? ()
(gdb) run
The "remote" target does not support "run". Try "help target" or
"continue".
(gdb) continue
Continuing.
^Cwarning: Cannot convert floating-point register value to
non-floating-point type.
value has been optimized out

Program received signal SIGINT, Interrupt.
0x0800133d in _main ()
at /home/psidhu/src/zephyr/zephyr-upstream/kernel/init.c:190
190 {

It seems like execution is always stuck on _main(), but I don't know
why. Does anyone have any idea what's going on / if I'm doing
something wrong?

Thank you,
- Pushpal
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


Re: I2C for STM32F3

Erwan Gouriou
 

Hi,

I don't have time to test this yet, but looking into STM32F303 reference manual,
it seems that I2C on F3 is clock independent and hence, we should sepcify clock
before using it.
It seems this case is particular to F3 (at least F303).

Can you have a try defining clock with fowlloing LL function?
  /* Set I2C2 clock source as SYSCLK */
  LL_RCC_SetI2CClockSource(uint32_t I2CxSource);
With I2CxSource:
  *         @arg @ref LL_RCC_I2C1_CLKSOURCE_HSI
  *         @arg @ref LL_RCC_I2C1_CLKSOURCE_SYSCLK
  *         @arg @ref LL_RCC_I2C2_CLKSOURCE_HSI (*)
  *         @arg @ref LL_RCC_I2C2_CLKSOURCE_SYSCLK (*)
  *         @arg @ref LL_RCC_I2C3_CLKSOURCE_HSI (*)
  *         @arg @ref LL_RCC_I2C3_CLKSOURCE_SYSCLK (*)

Erwan


On 12 October 2017 at 15:47, Yannis Damigos <giannis.damigos@...> wrote:


On Thu, Oct 12, 2017 at 3:52 PM, Wagenknecht, Daniel <Daniel.Wagenknecht@...> wrote:

Hi,

 

I’m working on a project that needs I2C functionality on a STM32F0 Chip. Since STM32F0 support is not yet merged into zephyr (I’m observing https://github.com/zephyrproject-rtos/zephyr/pull/4260), I started working with a stm32f3_disco board, which I had available and which uses the same I2C driver (stm32-i2c-v2), with only minor differences (F0 has a combined Event/Error Interrupt, F3 splits both up). I also took a look at the disco_l475_iot1 board for inspiration, because I2C support in Zephyr for this board is implemented and it uses the stm32-i2c-v2 driver as well, but I don’t have one of those boards to test with.

 

Just a little note before I explain the issues I’m running into on the stm32f3_disco: I basically did the same steps on stm32f4_disco board (which uses the stm32-i2c-v1 I2C driver) and got the  I2C bus working there.

I’m confident, that the basic procedure for adding I2C support to a STM32Fx based board is OK, since I got it working on the stm32f4_disco board this way.

 

Back to stm32f3_disco. See attachment for the changes I did to the repo based on zephyr-v1.9.0 release.

I’ve got it compiling with samples/drivers/i2c_fujitsu_fram example with a minor change and an I2C dummy device that acts like the fujitsu-fram (test-setup worked well with stm32f4_disco).

 

diff --git a/samples/drivers/i2c_fujitsu_fram/src/main.c b/samples/drivers/i2c_fujitsu_fram/src/main.c

 

@@ -13,5 +13,1 @@

-#if defined(CONFIG_SOC_QUARK_SE_C1000_SS)

-#define I2C_DEV CONFIG_I2C_SS_0_NAME

-#else

-#define I2C_DEV CONFIG_I2C_0_NAME

-#endif

+#define I2C_DEV "I2C_1"

 

After flashing it onto the stm32f3_disco board the I2C Pins (PB8, PB9) are high with pull-up (like intended), but nothing is happening on the bus. When I single step through  the code with the debugger I loose connection in

file drivers/i2c/i2c_ll_stm32_v2.c

function  msg_init(…)

line 41

 

Last step I can do is out of the LL_I2C_SetSlaveAddr(..) function. The debugger fails with the following message:

 

Error: jtag status contains invalid mode value - communication failure

Polling target stm32f3x.cpu failed, trying to reexamine

Examination failed, GDB will be halted. Polling again in 100ms

 

To reconnect to the board afterwards I need to disconnect it first, reset doesn’t help.

 

So if you know of any changes I missed or did wrong, or are familiar with this type of gdb-errors, please help me out here.

 

Sincerely

 

Daniel Wagenknecht

Softwaredeveloper, R&D

 

 

CLAGE GmbH

Pirolweg 1-5

21337 Lüneburg | Germany

 

Fon: +49 4131 8901-7906

Fax: +49 4131 83200

E-Mail: daniel.wagenknecht@...

www.clage.de

 

 

 

 

 


_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@...ct.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


Hi Daniel,

I was trying to get I2C working on stm32f3_disco a couple of months ago. You could find my local branch here https://github.com/ydamigos/zephyr/tree/f3disco (it needs a rebase to the master branch).
It just hangs after the line 41 of i2c_ll_stm32_v2.c like yours. It does not output any SYS_LOG on console. Below are the information I managed to collect.

Best regards,
Yannis

openocd debugserver output:
Info : halted: PC: 0x08000b98
Info : halted: PC: 0x08000afc
Info : halted: PC: 0x00000000

gdb output
(gdb) next
41              LL_I2C_SetTransferRequest(i2c, transfer);
(gdb) next
0x00000000 in ?? ()
(gdb) bt --full
No symbol "full" in current context.
(gdb) bt full
#0  0x00000000 in ?? ()
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) info frame
Stack level 0, frame at 0x0:
 pc = 0x0; saved pc = <unavailable>
 Outermost frame: previous frame identical to this frame (corrupt stack?)
 Arglist at unknown address.
 Locals at unknown address, Previous frame's sp is 0x0
(gdb) info registers
r0             0x0      0
r1             0x0      0
r2             0x0      0
r3             0x0      0
r4             0x0      0
r5             0x0      0
r6             0x0      0
r7             0x0      0
r8             0x0      0
r9             0x0      0
r10            0x0      0
r11            0x0      0
r12            0x0      0
sp             0x0      0x0
lr             0x0      0
pc             0x0      0x0
xPSR           0x0      0

_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel



Re: I2C for STM32F3

Yannis Damigos
 



On Thu, Oct 12, 2017 at 3:52 PM, Wagenknecht, Daniel <Daniel.Wagenknecht@...> wrote:

Hi,

 

I’m working on a project that needs I2C functionality on a STM32F0 Chip. Since STM32F0 support is not yet merged into zephyr (I’m observing https://github.com/zephyrproject-rtos/zephyr/pull/4260), I started working with a stm32f3_disco board, which I had available and which uses the same I2C driver (stm32-i2c-v2), with only minor differences (F0 has a combined Event/Error Interrupt, F3 splits both up). I also took a look at the disco_l475_iot1 board for inspiration, because I2C support in Zephyr for this board is implemented and it uses the stm32-i2c-v2 driver as well, but I don’t have one of those boards to test with.

 

Just a little note before I explain the issues I’m running into on the stm32f3_disco: I basically did the same steps on stm32f4_disco board (which uses the stm32-i2c-v1 I2C driver) and got the  I2C bus working there.

I’m confident, that the basic procedure for adding I2C support to a STM32Fx based board is OK, since I got it working on the stm32f4_disco board this way.

 

Back to stm32f3_disco. See attachment for the changes I did to the repo based on zephyr-v1.9.0 release.

I’ve got it compiling with samples/drivers/i2c_fujitsu_fram example with a minor change and an I2C dummy device that acts like the fujitsu-fram (test-setup worked well with stm32f4_disco).

 

diff --git a/samples/drivers/i2c_fujitsu_fram/src/main.c b/samples/drivers/i2c_fujitsu_fram/src/main.c

 

@@ -13,5 +13,1 @@

-#if defined(CONFIG_SOC_QUARK_SE_C1000_SS)

-#define I2C_DEV CONFIG_I2C_SS_0_NAME

-#else

-#define I2C_DEV CONFIG_I2C_0_NAME

-#endif

+#define I2C_DEV "I2C_1"

 

After flashing it onto the stm32f3_disco board the I2C Pins (PB8, PB9) are high with pull-up (like intended), but nothing is happening on the bus. When I single step through  the code with the debugger I loose connection in

file drivers/i2c/i2c_ll_stm32_v2.c

function  msg_init(…)

line 41

 

Last step I can do is out of the LL_I2C_SetSlaveAddr(..) function. The debugger fails with the following message:

 

Error: jtag status contains invalid mode value - communication failure

Polling target stm32f3x.cpu failed, trying to reexamine

Examination failed, GDB will be halted. Polling again in 100ms

 

To reconnect to the board afterwards I need to disconnect it first, reset doesn’t help.

 

So if you know of any changes I missed or did wrong, or are familiar with this type of gdb-errors, please help me out here.

 

Sincerely

 

Daniel Wagenknecht

Softwaredeveloper, R&D

 

 

CLAGE GmbH

Pirolweg 1-5

21337 Lüneburg | Germany

 

Fon: +49 4131 8901-7906

Fax: +49 4131 83200

E-Mail: daniel.wagenknecht@...

www.clage.de

 

 

 

 

 


_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


Hi Daniel,

I was trying to get I2C working on stm32f3_disco a couple of months ago. You could find my local branch here https://github.com/ydamigos/zephyr/tree/f3disco (it needs a rebase to the master branch).
It just hangs after the line 41 of i2c_ll_stm32_v2.c like yours. It does not output any SYS_LOG on console. Below are the information I managed to collect.

Best regards,
Yannis

openocd debugserver output:
Info : halted: PC: 0x08000b98
Info : halted: PC: 0x08000afc
Info : halted: PC: 0x00000000

gdb output
(gdb) next
41              LL_I2C_SetTransferRequest(i2c, transfer);
(gdb) next
0x00000000 in ?? ()
(gdb) bt --full
No symbol "full" in current context.
(gdb) bt full
#0  0x00000000 in ?? ()
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) info frame
Stack level 0, frame at 0x0:
 pc = 0x0; saved pc = <unavailable>
 Outermost frame: previous frame identical to this frame (corrupt stack?)
 Arglist at unknown address.
 Locals at unknown address, Previous frame's sp is 0x0
(gdb) info registers
r0             0x0      0
r1             0x0      0
r2             0x0      0
r3             0x0      0
r4             0x0      0
r5             0x0      0
r6             0x0      0
r7             0x0      0
r8             0x0      0
r9             0x0      0
r10            0x0      0
r11            0x0      0
r12            0x0      0
sp             0x0      0x0
lr             0x0      0
pc             0x0      0x0
xPSR           0x0      0


I2C for STM32F3

Daniel Wagenknecht
 

Hi,

 

I’m working on a project that needs I2C functionality on a STM32F0 Chip. Since STM32F0 support is not yet merged into zephyr (I’m observing https://github.com/zephyrproject-rtos/zephyr/pull/4260), I started working with a stm32f3_disco board, which I had available and which uses the same I2C driver (stm32-i2c-v2), with only minor differences (F0 has a combined Event/Error Interrupt, F3 splits both up). I also took a look at the disco_l475_iot1 board for inspiration, because I2C support in Zephyr for this board is implemented and it uses the stm32-i2c-v2 driver as well, but I don’t have one of those boards to test with.

 

Just a little note before I explain the issues I’m running into on the stm32f3_disco: I basically did the same steps on stm32f4_disco board (which uses the stm32-i2c-v1 I2C driver) and got the  I2C bus working there.

I’m confident, that the basic procedure for adding I2C support to a STM32Fx based board is OK, since I got it working on the stm32f4_disco board this way.

 

Back to stm32f3_disco. See attachment for the changes I did to the repo based on zephyr-v1.9.0 release.

I’ve got it compiling with samples/drivers/i2c_fujitsu_fram example with a minor change and an I2C dummy device that acts like the fujitsu-fram (test-setup worked well with stm32f4_disco).

 

diff --git a/samples/drivers/i2c_fujitsu_fram/src/main.c b/samples/drivers/i2c_fujitsu_fram/src/main.c

 

@@ -13,5 +13,1 @@

-#if defined(CONFIG_SOC_QUARK_SE_C1000_SS)

-#define I2C_DEV CONFIG_I2C_SS_0_NAME

-#else

-#define I2C_DEV CONFIG_I2C_0_NAME

-#endif

+#define I2C_DEV "I2C_1"

 

After flashing it onto the stm32f3_disco board the I2C Pins (PB8, PB9) are high with pull-up (like intended), but nothing is happening on the bus. When I single step through  the code with the debugger I loose connection in

file drivers/i2c/i2c_ll_stm32_v2.c

function  msg_init(…)

line 41

 

Last step I can do is out of the LL_I2C_SetSlaveAddr(..) function. The debugger fails with the following message:

 

Error: jtag status contains invalid mode value - communication failure

Polling target stm32f3x.cpu failed, trying to reexamine

Examination failed, GDB will be halted. Polling again in 100ms

 

To reconnect to the board afterwards I need to disconnect it first, reset doesn’t help.

 

So if you know of any changes I missed or did wrong, or are familiar with this type of gdb-errors, please help me out here.

 

Sincerely

 

Daniel Wagenknecht

Softwaredeveloper, R&D

 

 

CLAGE GmbH

Pirolweg 1-5

21337 Lüneburg | Germany

 

Fon: +49 4131 8901-7906

Fax: +49 4131 83200

E-Mail: daniel.wagenknecht@...

www.clage.de

 

 

 

 

 


Re: stm32f4_disco issues

Erwan Gouriou
 

Hi Pushpal,


Regarding the blinky issue. It's happening since CONFIG_GPIO_STM32_PORTD is not activated.
You should add it in board defconfig.

Then, regarding the debug issue.
Have you tried make BOARD=stm32f4_disco debug  ?
This should be working.

Just take care that you might have some dependency depending on the STLINK firmware on your board.
Current openocd support in zephyr for this board should only work on STLINK-V2.

On my side, I have a STLINK-V2.1 firmware and I had to do some changes to get it working:
In zephyr-sdk/sysroots/x86_64-pokysdk-linux/usr/share/openocd/scripts/board/stm32f4discovery.cfg
+source [find interface/stlink-v2-1.cfg]
-source [find interface/stlink-v2.cfg]
But then, worked directly.

HIH

Erwan


On 11 October 2017 at 23:38, Pushpal Sidhu <psidhu.devel@...> wrote:
Hi All,

I'm attempting to flash the samples/basic/blinky/ project on the
stm32f4_disco board, but am running into issues.

Here's a list of steps I run through:
 make BOARD=stm32f4_disco -C samples/basic/blinky/
 make BOARD=stm32f4_disco -C samples/basic/blinky/ flash

Then nothing happens on board (no LED blink after power cycle). I
attempt to debug
 make BOARD=stm32f4_disco -C samples/basic/blinky/ debugserver
 gdb -tui -ex "target remote :3333" ../outdir/stm32f4_disco/zephyr.elf

 For help, type "help".
 Type "apropos word" to search for commands related to "word"...
 Reading symbols from ../outdir/stm32f4_disco/zephyr.elf...done.
 Remote debugging using :3333
 warning: Architecture rejected target-supplied description
 warning: Cannot convert floating-point register value to
non-floating-point type.
 value has been optimized out
 0x00000000 in ?? ()
 (gdb) run
 The "remote" target does not support "run".  Try "help target" or "continue".
 (gdb) continue
 Continuing.
 ^Cwarning: Cannot convert floating-point register value to
non-floating-point type.
 value has been optimized out

 Program received signal SIGINT, Interrupt.
 0x0800133d in _main ()
     at /home/psidhu/src/zephyr/zephyr-upstream/kernel/init.c:190
 190     {

It seems like execution is always stuck on _main(), but I don't know
why. Does anyone have any idea what's going on / if I'm doing
something wrong?

Thank you,
 - Pushpal
_______________________________________________
Zephyr-devel mailing list
Zephyr-devel@lists.zephyrproject.org
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel


Re: [Zephyr-devil] Tiny tile Zephyr implementation

Jie Zhou <zhoujie@...>
 

Hi Graham,

Hmm interesting, which CONFIG settings? Also I want to use tinyTILE for a bluetooth application that I am working on. I need tinyTILE for its wearable size. For flashing on to tinyTILE, all of the bluetooth sample examples provided by zephyr does the same thing; application flashes fine, but when I open minicom to view the outputs, minicom freezes. This holds true for even Hello World the last time I ran that. If you ever get around testing with the curieNano let me know.

Thanks,
Jie

On Wed, Oct 11, 2017 at 7:07 PM, Graham Stott <gbcstott1@...> wrote:

Jie,

 

My board is in use at this time so I cannot do this test for you. However I did look at  the Bluetooth beacon sample and I see that it is setting some Bluetooth related CONFIG  settings that are not tested in the BOARD=tileTile make. They are tested  in the arduino_101 make. I suggest you do a make of the Bluetooth beacon sample using BOARD=Arduino_101 and see if that helps.

 

Graham

 

From: Jie Zhou [mailto:zhoujie@...]
Sent: Wednesday, October 11, 2017 6:09 PM


To: Graham Stott <gbcstott1@...>
Cc: zephyr-devel@lists.zephyrproject.org
Subject: Re: [Zephyr-devil] Tiny tile Zephyr implementation

 

Hi Graham,

 

Could you flash the beacon example in zephyr? The path is samples/bluetooth/beacon. You might have to flash the hci_uart example, which is also in the bluetooth sample directory, to update the firmware. If you can do that and open minicom and see the outputs then we might be in luck and will switch over to the curienano.

 

Thank you very much,

Jie 

 

On Wed, Oct 11, 2017 at 2:36 PM, Graham Stott <gbcstott1@...> wrote:

Jie,

 

I do not have the TinyTile board so I cannot try flashing it. However I do have the DFRobot CurieNano which is a similar board. I have no problem flashing this board. I used the instructions (DFU) for Arduino 101.

 

Graham

 

From: Jie Zhou [mailto:zhoujie@...]
Sent: Wednesday, October 11, 2017 3:11 PM
To: Graham Stott <gbcstott1@...>
Cc: zephyr-devel@lists.zephyrproject.org
Subject: Re: [Zephyr-devil] Tiny tile Zephyr implementation

 

Hi Graham,

Thanks for responding! About the similarities of TinyTILE and Arduino101, although the chip is the same, we have been trying to flash applications to tinyTILE for a while now. The arduino can be flash with DFU using the FTDI cable, but tinyTILE doesn't respond to minicom after flashing. We have some inconsistent success with flashing tinyTILE via Flyswatter and settling the port to ttyACM0. Either there is some issues with tinyTILE support from zephyr or the protocol of the chip is different than Arduino.

 

Thanks,

Jie

 

On Tue, Oct 10, 2017 at 12:29 PM, Graham Stott <gbcstott1@...> wrote:

I meant to also say to look at projects for Arduino/Genuine 101 as tiny Tile is a scaled down version of this board.

 

From: zephyr-devel-bounces@lists.zephyrproject.org [mailto:zephyr-devel-bounces@lists.zephyrproject.org] On Behalf Of Graham Stott
Sent: Tuesday, October 10, 2017 2:01 PM
To: 'Jie Zhou' <zhoujie@...>; zephyr-devel@lists.zephyrproject.org
Subject: Re: [Zephyr-devel] Tinytile Zephyr implementation

 

As tinyTile is basically just a version of the Intel® Curie™ module, you can look for projects under Curie. Yes. It has additional pins but the rest is the same

 

Graham

 

From: zephyr-devel-bounces@lists.zephyrproject.org [mailto:zephyr-devel-bounces@lists.zephyrproject.org] On Behalf Of Jie Zhou
Sent: Tuesday, October 10, 2017 1:21 AM
To: zephyr-devel@lists.zephyrproject.org
Subject: [Zephyr-devel] Tinytile Zephyr implementation

 

Hi All,

 

Has anyone done anything with tinyTILE? Since the board is quite new I was wondering if someone has done a project with Zephyr OS on tinyTILE. The specs of the chip looks promising for IoT implementations. Any info or the setup you are using will help. I'm trying to evaluate the capability of tinyTILE with Zephyr.

 

Thanks,

Jie

 

 



Re: [Zephyr-devil] Tiny tile Zephyr implementation

Graham Stott <gbcstott1@...>
 

Jie,

 

My board is in use at this time so I cannot do this test for you. However I did look at  the Bluetooth beacon sample and I see that it is setting some Bluetooth related CONFIG  settings that are not tested in the BOARD=tileTile make. They are tested  in the arduino_101 make. I suggest you do a make of the Bluetooth beacon sample using BOARD=Arduino_101 and see if that helps.

 

Graham

 

From: Jie Zhou [mailto:zhoujie@...]
Sent: Wednesday, October 11, 2017 6:09 PM
To: Graham Stott <gbcstott1@...>
Cc: zephyr-devel@...
Subject: Re: [Zephyr-devil] Tiny tile Zephyr implementation

 

Hi Graham,

 

Could you flash the beacon example in zephyr? The path is samples/bluetooth/beacon. You might have to flash the hci_uart example, which is also in the bluetooth sample directory, to update the firmware. If you can do that and open minicom and see the outputs then we might be in luck and will switch over to the curienano.

 

Thank you very much,

Jie 

 

On Wed, Oct 11, 2017 at 2:36 PM, Graham Stott <gbcstott1@...> wrote:

Jie,

 

I do not have the TinyTile board so I cannot try flashing it. However I do have the DFRobot CurieNano which is a similar board. I have no problem flashing this board. I used the instructions (DFU) for Arduino 101.

 

Graham

 

From: Jie Zhou [mailto:zhoujie@...]
Sent: Wednesday, October 11, 2017 3:11 PM
To: Graham Stott <gbcstott1@...>
Cc: zephyr-devel@...
Subject: Re: [Zephyr-devil] Tiny tile Zephyr implementation

 

Hi Graham,

Thanks for responding! About the similarities of TinyTILE and Arduino101, although the chip is the same, we have been trying to flash applications to tinyTILE for a while now. The arduino can be flash with DFU using the FTDI cable, but tinyTILE doesn't respond to minicom after flashing. We have some inconsistent success with flashing tinyTILE via Flyswatter and settling the port to ttyACM0. Either there is some issues with tinyTILE support from zephyr or the protocol of the chip is different than Arduino.

 

Thanks,

Jie

 

On Tue, Oct 10, 2017 at 12:29 PM, Graham Stott <gbcstott1@...> wrote:

I meant to also say to look at projects for Arduino/Genuine 101 as tiny Tile is a scaled down version of this board.

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Graham Stott
Sent: Tuesday, October 10, 2017 2:01 PM
To: 'Jie Zhou' <zhoujie@...>; zephyr-devel@...
Subject: Re: [Zephyr-devel] Tinytile Zephyr implementation

 

As tinyTile is basically just a version of the Intel® Curie™ module, you can look for projects under Curie. Yes. It has additional pins but the rest is the same

 

Graham

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Jie Zhou
Sent: Tuesday, October 10, 2017 1:21 AM
To: zephyr-devel@...
Subject: [Zephyr-devel] Tinytile Zephyr implementation

 

Hi All,

 

Has anyone done anything with tinyTILE? Since the board is quite new I was wondering if someone has done a project with Zephyr OS on tinyTILE. The specs of the chip looks promising for IoT implementations. Any info or the setup you are using will help. I'm trying to evaluate the capability of tinyTILE with Zephyr.

 

Thanks,

Jie

 

 


Re: [Zephyr-devil] Tiny tile Zephyr implementation

Jie Zhou <zhoujie@...>
 

Hi Graham,

Could you flash the beacon example in zephyr? The path is samples/bluetooth/beacon. You might have to flash the hci_uart example, which is also in the bluetooth sample directory, to update the firmware. If you can do that and open minicom and see the outputs then we might be in luck and will switch over to the curienano.

Thank you very much,
Jie 

On Wed, Oct 11, 2017 at 2:36 PM, Graham Stott <gbcstott1@...> wrote:

Jie,

 

I do not have the TinyTile board so I cannot try flashing it. However I do have the DFRobot CurieNano which is a similar board. I have no problem flashing this board. I used the instructions (DFU) for Arduino 101.

 

Graham

 

From: Jie Zhou [mailto:zhoujie@...]
Sent: Wednesday, October 11, 2017 3:11 PM
To: Graham Stott <gbcstott1@...>
Cc: zephyr-devel@lists.zephyrproject.org
Subject: Re: [Zephyr-devil] Tiny tile Zephyr implementation

 

Hi Graham,

Thanks for responding! About the similarities of TinyTILE and Arduino101, although the chip is the same, we have been trying to flash applications to tinyTILE for a while now. The arduino can be flash with DFU using the FTDI cable, but tinyTILE doesn't respond to minicom after flashing. We have some inconsistent success with flashing tinyTILE via Flyswatter and settling the port to ttyACM0. Either there is some issues with tinyTILE support from zephyr or the protocol of the chip is different than Arduino.

 

Thanks,

Jie

 

On Tue, Oct 10, 2017 at 12:29 PM, Graham Stott <gbcstott1@...> wrote:

I meant to also say to look at projects for Arduino/Genuine 101 as tiny Tile is a scaled down version of this board.

 

From: zephyr-devel-bounces@lists.zephyrproject.org [mailto:zephyr-devel-bounces@lists.zephyrproject.org] On Behalf Of Graham Stott
Sent: Tuesday, October 10, 2017 2:01 PM
To: 'Jie Zhou' <zhoujie@...>; zephyr-devel@lists.zephyrproject.org
Subject: Re: [Zephyr-devel] Tinytile Zephyr implementation

 

As tinyTile is basically just a version of the Intel® Curie™ module, you can look for projects under Curie. Yes. It has additional pins but the rest is the same

 

Graham

 

From: zephyr-devel-bounces@lists.zephyrproject.org [mailto:zephyr-devel-bounces@lists.zephyrproject.org] On Behalf Of Jie Zhou
Sent: Tuesday, October 10, 2017 1:21 AM
To: zephyr-devel@lists.zephyrproject.org
Subject: [Zephyr-devel] Tinytile Zephyr implementation

 

Hi All,

 

Has anyone done anything with tinyTILE? Since the board is quite new I was wondering if someone has done a project with Zephyr OS on tinyTILE. The specs of the chip looks promising for IoT implementations. Any info or the setup you are using will help. I'm trying to evaluate the capability of tinyTILE with Zephyr.

 

Thanks,

Jie

 



Re: [Zephyr-devil] Tiny tile Zephyr implementation

Graham Stott <gbcstott1@...>
 

Jie,

 

I do not have the TinyTile board so I cannot try flashing it. However I do have the DFRobot CurieNano which is a similar board. I have no problem flashing this board. I used the instructions (DFU) for Arduino 101.

 

Graham

 

From: Jie Zhou [mailto:zhoujie@...]
Sent: Wednesday, October 11, 2017 3:11 PM
To: Graham Stott <gbcstott1@...>
Cc: zephyr-devel@...
Subject: Re: [Zephyr-devil] Tiny tile Zephyr implementation

 

Hi Graham,

Thanks for responding! About the similarities of TinyTILE and Arduino101, although the chip is the same, we have been trying to flash applications to tinyTILE for a while now. The arduino can be flash with DFU using the FTDI cable, but tinyTILE doesn't respond to minicom after flashing. We have some inconsistent success with flashing tinyTILE via Flyswatter and settling the port to ttyACM0. Either there is some issues with tinyTILE support from zephyr or the protocol of the chip is different than Arduino.

 

Thanks,

Jie

 

On Tue, Oct 10, 2017 at 12:29 PM, Graham Stott <gbcstott1@...> wrote:

I meant to also say to look at projects for Arduino/Genuine 101 as tiny Tile is a scaled down version of this board.

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Graham Stott
Sent: Tuesday, October 10, 2017 2:01 PM
To: 'Jie Zhou' <zhoujie@...>; zephyr-devel@...
Subject: Re: [Zephyr-devel] Tinytile Zephyr implementation

 

As tinyTile is basically just a version of the Intel® Curie™ module, you can look for projects under Curie. Yes. It has additional pins but the rest is the same

 

Graham

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Jie Zhou
Sent: Tuesday, October 10, 2017 1:21 AM
To: zephyr-devel@...
Subject: [Zephyr-devel] Tinytile Zephyr implementation

 

Hi All,

 

Has anyone done anything with tinyTILE? Since the board is quite new I was wondering if someone has done a project with Zephyr OS on tinyTILE. The specs of the chip looks promising for IoT implementations. Any info or the setup you are using will help. I'm trying to evaluate the capability of tinyTILE with Zephyr.

 

Thanks,

Jie

 


Re: [Zephyr-devil] Tiny tile Zephyr implementation

Jie Zhou <zhoujie@...>
 

Hi Graham,

Thanks for responding! About the similarities of TinyTILE and Arduino101, although the chip is the same, we have been trying to flash applications to tinyTILE for a while now. The arduino can be flash with DFU using the FTDI cable, but tinyTILE doesn't respond to minicom after flashing. We have some inconsistent success with flashing tinyTILE via Flyswatter and settling the port to ttyACM0. Either there is some issues with tinyTILE support from zephyr or the protocol of the chip is different than Arduino.

Thanks,
Jie

On Tue, Oct 10, 2017 at 12:29 PM, Graham Stott <gbcstott1@...> wrote:

I meant to also say to look at projects for Arduino/Genuine 101 as tiny Tile is a scaled down version of this board.

 

From: zephyr-devel-bounces@lists.zephyrproject.org [mailto:zephyr-devel-bounces@lists.zephyrproject.org] On Behalf Of Graham Stott
Sent: Tuesday, October 10, 2017 2:01 PM
To: 'Jie Zhou' <zhoujie@...>; zephyr-devel@lists.zephyrproject.org
Subject: Re: [Zephyr-devel] Tinytile Zephyr implementation

 

As tinyTile is basically just a version of the Intel® Curie™ module, you can look for projects under Curie. Yes. It has additional pins but the rest is the same

 

Graham

 

From: zephyr-devel-bounces@lists.zephyrproject.org [mailto:zephyr-devel-bounces@lists.zephyrproject.org] On Behalf Of Jie Zhou
Sent: Tuesday, October 10, 2017 1:21 AM
To: zephyr-devel@lists.zephyrproject.org
Subject: [Zephyr-devel] Tinytile Zephyr implementation

 

Hi All,

 

Has anyone done anything with tinyTILE? Since the board is quite new I was wondering if someone has done a project with Zephyr OS on tinyTILE. The specs of the chip looks promising for IoT implementations. Any info or the setup you are using will help. I'm trying to evaluate the capability of tinyTILE with Zephyr.

 

Thanks,

Jie



stm32f4_disco issues

Pushpal Sidhu
 

Hi All,

I'm attempting to flash the samples/basic/blinky/ project on the
stm32f4_disco board, but am running into issues.

Here's a list of steps I run through:
make BOARD=stm32f4_disco -C samples/basic/blinky/
make BOARD=stm32f4_disco -C samples/basic/blinky/ flash

Then nothing happens on board (no LED blink after power cycle). I
attempt to debug
make BOARD=stm32f4_disco -C samples/basic/blinky/ debugserver
gdb -tui -ex "target remote :3333" ../outdir/stm32f4_disco/zephyr.elf

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ../outdir/stm32f4_disco/zephyr.elf...done.
Remote debugging using :3333
warning: Architecture rejected target-supplied description
warning: Cannot convert floating-point register value to
non-floating-point type.
value has been optimized out
0x00000000 in ?? ()
(gdb) run
The "remote" target does not support "run". Try "help target" or "continue".
(gdb) continue
Continuing.
^Cwarning: Cannot convert floating-point register value to
non-floating-point type.
value has been optimized out

Program received signal SIGINT, Interrupt.
0x0800133d in _main ()
at /home/psidhu/src/zephyr/zephyr-upstream/kernel/init.c:190
190 {

It seems like execution is always stuck on _main(), but I don't know
why. Does anyone have any idea what's going on / if I'm doing
something wrong?

Thank you,
- Pushpal

4701 - 4720 of 8189