Which serial device do you connect minicom to? How is the device connected to your host? TinyTILe board is configured to use USB CDC, so the console output is on ttyACM, if you flash the Arduino board image, the console will use the UART device.

 

Anas

 

From: zephyr-devel-bounces@... [mailto:zephyr-devel-bounces@...] On Behalf Of Jie Zhou
Sent: Friday, October 13, 2017 2:58 PM
To: Graham Stott <gbcstott1@...>; Li, Jun R <jun.r.li@...>; zephyr-devel@...

Subject: Re: [Zephyr-devel] [Zephyr-devil] Tiny tile Zephyr implementation

 

 

On Fri, Oct 13, 2017 at 6:47 AM Li, Jun R <jun.r.li@...> wrote:

 Yeah sorry I meant "make BOARD=tinytile". Although it works and applications can flash with this command. When I open minicom to view the outputs. Minicom freezes. This does not happen with make BOARD=arduino_101

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

 

 

 

 

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

 Yeah sorry I meant "make BOARD=tinytile". Although it works and applications can flash with this command. When I open minicom to view the outputs. Minicom freezes. This does not happen with make BOARD=arduino_101

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

 

 

 

 

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

 

 

 

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

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@... <mailto:giannis.damigos@...>> wrote:



On Thu, Oct 12, 2017 at 3:52 PM, Wagenknecht, Daniel <Daniel.Wagenknecht@... <mailto: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 <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@... <mailto:daniel.wagenknecht@...>____

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

__ __

__ __

__ __

__ __

__ __


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

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@... <mailto:giannis.damigos@...>> wrote:



On Thu, Oct 12, 2017 at 3:52 PM, Wagenknecht, Daniel <Daniel.Wagenknecht@... <mailto: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 <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@... <mailto:daniel.wagenknecht@...>____

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

__ __

__ __

__ __

__ __

__ __


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

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@...
https://lists.zephyrproject.org/mailman/listinfo/zephyr-devel

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