ATBTLC1000-MR110CA Serial Coms Confusion

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

Dear ATMEL/MICROCHIP

 

The design/documentation of the serial coms link to the ATBTLC1000-MR110CA seems to be a total Dogs Dinner. From what I have read I don't think it's just me having trouble, is it?. (Readers if you agree please comment below).

 

I have designed a 4 layer PCB, for a client, which includes a SAMD21 micro, connected via UART to an ATBTLC1000-MR110CA. I have followed the schematic on page 15 of "Atmel-42514-ATBTLC1000-MR110CA-BLE-Module_Datasheet.pdf" which shows the following connections:

1) UART_RXD

2) UART_TXD

3) UART_CTS

4) UART_RTS

5) Wake

6) Chip_EN

So I have made these connections on my PCB. The datasheet also shows SPI connections but the BluSDK does not support SPI so I have not connected those pins to my SAMD21.

The datasheet calls this connection a 4 wire connection (even though it has 6 wires), which, I assume, means it is the correct connection for use with the BluSDK with the settings:

UART_FLOWCONTROL_6WIRE_MODE=false

UART_FLOWCONTROL_4WIRE_MODE=true

Q1) Please can someone confirm if this is correct?

 

According to Page 30 of "ATBTLC1000-BluSDK-v5.0-Release-Notes.pdf" The only allowed alternative BluSDK setting is:

UART_FLOWCONTROL_6WIRE_MODE=true

UART_FLOWCONTROL_4WIRE_MODE=false

Q2) What is the required connection between the SAMD21 and ATBTLC1000-MR110CA for this setting? Two UARTS? Connected how? Why is there not a schematic showing this in the datasheet?

 

Q3) Which of the above two connection methods is recommended going forward for a mass produced product?

 

With the 4 wire connection described above, I was able to work out conf_serialdrv.h (and conf_console.h) settings for my PCB layout and make progress with my software and get the battery service, Device Information Service and a couple of my own custom services working on this board as a BLE peripheral.

However, I started to get AT_BLE_TIMEOUT errors after the code had been running for a few minutes.

Q4) Does this sound like a UART coms problem? Or is there likely some other explanation, e.g. a bug in my code? Any ideas what it might be?

 

Annex 12 on Page 30-31 of "ATBTLC1000-BluSDK-v5.0-Release-Notes.pdf" says the following:

Q5) I can't make any sense of this. Can someone translate this into meaningful English sentences so people can understand what it is trying to say, please?

 

Q6) What is 2 wire mode? Is this another viable connection scheme not shown in the datasheet?

 

With the 4 wire settings above I stepped through the code and found that pf_cfg.bus_info.bus_flow_control_enabled is being set = false by the BluSDK functions.

Q7) Is this equivalent to "busConfig.bus_flow_control_enabled" in the text above?

 

However looking at the UART data with a logic analyser I see about 2.2 seconds of solid data download (at 115200 baud) on initialisation of the ATBTLC1000-MR110CA, which I take to be the patch download that the above text says is disabled when busConfig.bus_flow_control_enabled = false.

Q7) Can you explain why this seems to show the above-quoted text is nonsense.

 

Annex 12 on Page 32 of "ATBTLC1000-BluSDK-v5.0-Release-Notes.pdf" (the same document quoted above, which seems to be full of nonsense), describes a "BTLC1000 Hardware Flow control 4-Wire Mode E-Fuse Write Procedure" with a big red warning about it being irreversible. Since my board seemed to be working OK for a while, before the AT_BLE_TIMEOUT errors showed up, I am in two minds about whether I need to do this procedure on my ATBTLC1000-MR110CA or not. I am using the 4 wire Mode as I understand it.

Q8) Do I have to do the E-Fuse write procedure to correct the coms errors I am experiencing? Or does the level of functionality I have achieved show this is not needed (or has been done) and the problem is in my code?

 

I wondered if I needed to do the E-Fuse write procedure or if it was already set so I wired up my Atmel-ICE 3v3, GND, SWDIO & SWDCLK to the ATBTLC1000-MR110CA on my PCB.

I then ran the "EfuseBlockProgram.exe" to try to find if the fuse was set already or not. However, it did not find the ICE and I think it said that no Segger J-Link was connected.

Q9) Why was it looking for a Seger J-Link instead of an Atmel-ICE?

 

So I tried using Atmel Studio to access the Fuse settings via the Atmel-ICE but it would not connect to the ATBTLC1000-MR110CA device either, so I gave up until I get confirmation that I need to do this. Perhaps I have a connection problem.

Q10) The document mentions using a SAM-ICE but I only have an Atmel-ICE (a later model) If I need to set this fuse can I use my Atmel-ICE or do I have to buy another tool? If so which one?

 

Q11) If this product I am designing goes into production WILL WE HAVE TO DO THIS E-FUSE PROGRAMMING ON EVERY SINGLE UNIT USED IN PRODUCTION ?!?!?!

Q12) Should I use 6 wire mode to avoid haveing to do this?

 

Page 6 of "Atmel-42526-ATBTLC1000-BluSDK-Platform-Porting-Guide_USERGUIDE.pdf" says the following:

Q13) What hardware fix? When will this come into effect? Has it been done on the unit I have? How will this be handled?

 

 

As you can probably tell I am just about in a state of terminal confusion with all of this.

Q14) Why is, what should be a simple serial interface, being made so hard?

 

Any practical advice on all this will be wonderful.

 

Thanks.

 

 

 

 

 

 

 

 

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

Update:

OK. I borrowed a Segger J-Link LITE CortexM to burn the eFuse but it wouldn't work. See screenshot below:

Screenshot

Why would it find the chip and then timeout when verifying or programming the fuse?

Could the Segger J-Link LITE be unsuitable? Do I have to use a SAM-ICE?

Or is the security bit set on this module? REV_?

Module

 

Thanks.