[Homemade DA14531 bracelet (similar to Xiaomi bracelet 4/5) development kit] Supporting tutorial 1: Development environment + Getting started..

辛昕

[Homemade DA14531 bracelet (similar to Xiaomi bracelet 4/5) development kit] Supporting tutorial 1: Development environment + Getting started.. [Copy link]

 

Other links for this series of tutorials are as follows:

Supporting tutorial 3: Project git description and my BSP https://en.eeworld.com/bbs/thread-1270515-1-1.html

Paste the content directory of the following floor:

1-0. Reason for the first post (i.e. this post)

1-1. Required for development environment;

1-2. Simple description of Keil5 MDK configuration for SDK (_6.0.20.1338) and (non-Bluetooth) simple peripheral routines

1-3. The DA14531 program runs in RAM

1-4. The program runs in RAM? So, how big is the FLASH and RAM of DA14531?

1-5. SmartBond Flash Programmer and programming address size issue

1-6. How to use JLink's RTT (replace and save debugging serial port)

1-7. Telnet method, XShell connects to JLink RTT to achieve more powerful logging function

1-8. Daily Operation - Keil5 MDK Debug What are we viewing?

1-9. Get out of the debugging and development world - use JLink Commander to debug.

1-10. Ozone, a graphical JLink debugging tool, launched by JLink;

1-11. A brief introduction to the non-ble peripheral_project example structure.

I was so nauseous about this yesterday that I stopped writing. Later I thought about it and decided to open a separate post to talk about it.

Although this is a very simple question, I suddenly want to talk about the BSP habit I have formed over the years.

The following is the main text of the first post:

Friends who are familiar with (disassembling) Xiaomi bracelets should be familiar with Dialog Semiconductor's series of Bluetooth SoC DA145XX DA146XX.

I worked on wearable development a few years ago and was very interested in this type of product.

However, I am not very impressed with the general functions of current bracelets.

So the idea of DIY came to my mind very early.

However, DIYing a finished product is far from as simple as drawing a board, patching chips and writing code.

Just the shell makes me, a person who mainly writes code and has no knowledge of structure, feel very embarrassed...

——The first step of this kit is to launch a PCBA that is compatible with Xiaomi Mi Band 4/5 in appearance. Later, I will work hard on the shell, or hope that there is

Friends who understand and are familiar with this area can join and help

——Because I have no money to give you.

Rather than saying that I am very interested in bracelets, it is better to say that I am very interested in the form of bracelets.

There is no other reason - because it is worn on the human hand, is lighter and smaller than a mobile phone - to be precise, users feel less noticeable when using it than when using a mobile phone.

This is also the most valuable aspect of wearable products - in my opinion.

However, I am not very interested in the functions of common bracelets on the market.

For example, step counting - so, in my version, one is because I don't have a cold, and the other is because I don't have a cold.

I chose the smallest DA14531 chip. At present, all IO ports have been used up by me, so although I wanted to reserve a GSENSOR chip

But it is not possible for the time being.

(Later, if necessary, I will consider changing to an MCU from the same series).

My bigger hope, actually, is to make this thing into an open kit.

So that all other people who, like me, want to DIY a bracelet-shaped product can have a ready-made platform available.

Because, I have never seen anything like this before.

Once upon a time, the so-called Baidu bracelet did not actually have the hardware part leaked. I remember it seemed like that. Not to mention how well the software was written, it was purely open source software.

Of course, for a while afterwards, I also saw some so-called open source bracelet projects based on DA14580——

These things come with a... well, what should I say? That thing, I'm sure you wouldn't want to wear on your hand.

So, when I made this thing, I chose to make it similar to the Xiaomi bracelet in appearance, without considering any copyright risks that might be involved.

My goal is to replicate the Xiaomi Mi Band in appearance as much as possible and utilize its surrounding ecosystem to a certain extent.

For example, a small number of various types of bracelet straps have been developed.

On the other hand, I personally think that Xiaomi Mi Band has evolved from generation to generation in terms of cost performance and appearance, and has now reached Xiaomi Mi 8.

Personally, I have owned almost every model except the second generation and the latest 8.

I really appreciate the improvement in its appearance.

Despite being a DIY person, I have no confidence that I can replicate its beauty.

But it never hurts to set a shining example.

Of course, this is all later.

At present, the first step is still a PCBA. Currently, this board has been handed over to forum member @Rex for drawing.

I believe that I will be able to go to LiChuang to print and paste materials soon.

In this post, I will focus on doing some things that I think are necessary, such as development board tutorials.

Because there are actually very few tutorials for the DA14XXX series of MCUs, let alone such a rich ecosystem like STM32.

Really - if you go to Taobao, except for buying official development boards shipped from overseas - they are very expensive.

The USB part, which is the one I have in my hand now, costs nearly 300 yuan.

The pro version is more expensive, costing more than a thousand dollars.

Apart from this, I haven’t seen any minimum system board or development board.

In fact, let alone DA14531, except for the earliest DA14580 and DA14585, relatively cheap development boards can be seen on Taobao (that is, the regular price of more than 100 yuan).

Apart from that, it is basically difficult to find resources for other newer models, so you can only make the boards yourself.

As for tutorials, it’s not that there aren’t any, but they are copied from thousands of times and there are only a few of them.

While I was getting familiar with and using DA14531, I also went through these tutorials.

But I feel that what they said is very superficial and they basically do not mention many crucial issues.

So, while we wait for our own development kit hardware, which is designed from the beginning for the finished bracelet, to be released,

I will gradually post my process of becoming familiar with, learning, and understanding this board in this period of time under this post.

Just for information.

At the same time, Dialog did not officially port FreeRTOS to DA14531, but used the pseudo-system Rivera Waves.

However, my personal experience is that it is actually quite troublesome to write programs for this type of system that does not have truly independent threads and preemptive features.

So, I transplanted it myself.

At present, it has been preliminarily completed and the test of running the basic creation task has been completed.

Other subsequent tests will be completed and supplemented.

辛昕

1-1. Development environment requirements

The development environment of DA14531 is the familiar Keil JLink, which is very good.

Briefly describe what you need so that you can prepare and save time.

a.Keil5 MDK

b.DA1453x pack

c.SDK (SDK_6.0.20.1338)

d.JLink (v7.92h)

e.SmartBond Flash Programmer

1. Install Keil5 MDK and DA1453x series pack

There is no need to say much about this, but I would like to make two points:

DA14531 is a relatively new device, so if you are like me and have updated the Keil5 version a long time ago, it is likely that it is not supported, so you need to upgrade to a newer version.

At present, I have tested and confirmed that 5.36 is definitely possible, and I am using this version;

As for the pack file of DA14531, it depends on keil5 to update itself. I don't know if it has something to do with scientific Internet access. Anyway, it basically fails, so I usually complete it offline. I won't say much here, just attach the latest DA14531.DFP file;

The second point to note is that Keil5 no longer uses the old AC5 compiler from version 5.2x, but adopts AC6 . This thing has changed a lot. Of course, I haven't done much research on the specifics.

But it has caused significant changes to development. For example, the STM32 project generated by the current STM32CubeMX is still only applicable to the previous AC5 compiler, so when we do it, we still need to install the AC5 compiler separately and set it up in Keil5; ( This has nothing to do with DA14531. I mentioned it in the relevant posts about STM32G030 before. You can see it there if you need it ).

Of course, the latest DA14531 SDK6 uses the AC6 compiler, so there is no need to worry about it. However, later, because I ported FreeRTOS myself, there will be some changes. These will be discussed in detail in the next lecture when I specifically mention the porting of FreeRTOS.

DialogSemiconductor.DA1453x_DFP.1.0.4.pack (4.32 MB, downloads: 21)

2024-1-18 01:55 上传

点击文件名下载附件

辛昕

1-2. SDK ( _6.0.20.1338 ) and Keil5 MDK configuration instructions for (non-Bluetooth) simple peripheral examples

Currently, the latest SDK version for the DA145XX series is SDK6, and the latest sub-version is the above version.

You can download it from Renesas official website (Dialog Semiconductor was acquired by Renesas, and now it is Renesas' chip)

Of course, I will upload the code I developed to gitee in the future. You can download and synchronize my latest code from there.

There is a brief description of Get Started for SDK on the Renesas official website, but it is just a web page, so I didn’t download it.

You can click to view: https://lpccs-docs.renesas.com/Tutorial_SDK6/index.html

The following picture is from the SDK Architecture section

At present, for the sake of simplicity, starting with the most basic routine will help to more easily understand the settings of the DA14531 project files and some common things.

What's more, the initial program I want to implement does not include Bluetooth.

So we start with peripheral_examples, which is the most basic single peripheral example.

1. Start from the blinky routine

This is basically the simplest one among all the examples, just a simple LED flashing, and at most a serial port printing;

First, select DA14531 from the red line in the picture, which is called "Engineering Options".

For the routine, it does not require any settings, just compile and download.

But we still have to mention a few important points that will be introduced later.

First of all, the chip model

In the example, it defaults to ARMCM0P, which is Cortex M0+

It turns out that choosing this option doesn't matter at all, and it can still run successfully.

However, under this option, there are actually some problems with the configuration of ROM and RAM——

Because obviously, the DA14531's RAM isn't that big, and it doesn't start at 0x20000000 either.

If you followed the previous instructions, the DFP file for DA14531 was successfully installed.

Then, you can see DA14531 in Device, and then let's take a look at its ROM and RAM settings.

This is the ROM RAM size and starting address that matches the DA14531 chip.

The RAM of DA14531 is only 48K. Moreover, unlike the 32-bit microcontrollers we have used before, such as STM32, its starting address is not 0x20000000

Similarly, the ROM of DA14531 is different from the STM32 ROM we are familiar with, which is used to store our application programs, and it does not start from 0x08000000.

We will discuss the most critical issues about DA14531's ROM and RAM, as well as the most important question - where is the program?

Just mentioning this place now.

However, this place, in fact, I still don’t particularly understand it——

1. Let's put ROM aside and talk about RAM. It's OK if the size is different, even the starting address is wrong. Why can we compile, debug and run normally with the ARMCM0P setting?
2. There is a similar problem. When I was porting and testing FreeRTOS later, I found a problem that was also difficult to understand:

By default, the heap size of DA14531 is only 256Byte (0x0000 0100). However, for the default case of FreeRTOS, it involves dynamic allocation, and the created tasks are also dynamic tasks. At this time, after verification, you will find that the minimum available heap size in FreeRTOSConfig.h must be set to more than 1.5K to run a simple task normally.

However, 1.5K is obviously much larger than the heap size in the DA14531 startup file.

Why can it still run normally without changing the heap size?

I don't have answers to these two questions at the moment. I guess the former involves looking at the .sct file mentioned later, and the latter may involve FreeRTOS's own implementation code;

In addition, regarding these two sct, I have tried a simple replacement, and there is no difference in the compilation and debugging of the routine. I don’t know what the difference is yet.

I only know that Clang is a compiler, but I don’t really understand what is the difference between it and the original C/C++ compiler?

This is a brief introduction to the project configuration in Keil5 MDK.

The rest is relatively simple.

Just like usual, click Debug to start debugging;

USB-DEV P01 and P06 have incorrect silkscreen printing

The last thing I want to say is that if, like me, you start with the official USB-Dev development board, no one on Taobao has made a DA14531 development board so far.

So, when using the serial port output, you should pay attention to the fact that the silk screen of this USB-DEV, P01 and P06 are interchanged——

I discovered this when I found that there was no output on the serial port and went back to check the schematic.

In fact, these two pictures are symmetrical and opposite. In practice, the schematic diagram should be taken as the standard. If you connect according to the silk screen, you will find that the serial port has no output;

But the next issue is quite different from what we have done with STM32/51 in the past.

That is, if you try to power off and restart after debugging, you will find that the program does not run as it did when you just debugged it. What's going on?

Here is a brief conclusion that will be mentioned later:

According to the hardware configuration of this USB-DEV - in fact, this method is also the method used most of the time when DA14531 is used as a single master control.

It is to connect a spi flash chip outside the chip.

Then use the tools provided by DA14531 to burn the program into the external spi Flash.

In other words, once your code debugging is stable and you no longer need to adjust it or consider upgrading it, you can also burn the program into the OTP on the chip.

OTP is also a type of memory. Unlike FLASH, it can only be burned once.

But its cost is much lower than FLASH.

Therefore, for those firmware that are stable and do not need to be modified, the use of OTP can significantly reduce costs, so it is also widely used in mature mass-produced products.

The OTP size configured in the DA14531 chip is 32KB.

辛昕

1-3.DA14531 programs are run in RAM

This question - I actually think it is the most important part of this post, and it contains a lot of content, so I hope you will read it patiently.

Whether it is 51 or STM32, we are already accustomed to the ROM+RAM, or FLASH+RAM structure configuration.

At first glance, the DA14531 chip also has ROM and RAM - and it is divided into 3 RAM blocks.

And the ROM seems to be quite large, 144KB.

However, this ROM is completely different from the ROM we are familiar with - what I mean is that the application code you write is not placed here. This 144KB is actually used to store the Bluetooth protocol stack and bootloader ( of course, the datasheet does not call it that, but that's what it means ).

We can confirm this from the Memory Map in the datasheet:

Here is a mention:

DA14531 is not like STM32, which has a lot of information and various tutorials. It also does not have any RM or register manual.

Basically, all the information about DA14531 is in this 300+ page datasheet.

So, if you want to know something, don’t have any illusions. You can basically only find the answer in this 300-plus page datasheet.

Remember what we saw earlier in the Target tab of Option in Keil5?

The address of the ROM there is between 0x07F00000 and 0x07F24000 (0x24000 is 144KB if you do the math)

This thing is the 144KB ROM in the block diagram above.

Simply put, this ROM is not for us;

At this point, you may be very curious, if this is the case, then where is the code we wrote stored and run?

Whether you just learned about the so-called "execution in RAM" from Baidu or because you are like me and have worked on other Bluetooth before, you may suddenly remember the so-called "execution in RAM" .

At this time, the question we need to further understand is -

If so, where is the code normally stored, and how is it loaded into RAM at power-up?

——This question is very important because it involves two very important things——

1. DA14531, how much CODE and DATA do you have available?

2. In case of a crash, you can use the map to locate the function where the crash occurred. Then you will know where your code is running.

At this time, what we need to see is how the code is loaded into RAM after the MCU is powered on.

Also in the datasheet——

This thing is called BootROM Sequence. If you don't know it and haven't done it, then you——

You can only do the same as me, go through the datasheet directory or even the entire datasheet, and then half rely on guessing and half rely on reading the original text to confirm whether this thing is what you want to know.

This flowchart looks complicated—and in fact, it is quite complicated.

However, in general, you will find that no matter which way you go (see the flowchart on the right), it will eventually reach "Download Code to SRAM".

That is to say, among the many ways on the right, whether it is transmitted from the serial port, SPI, or from the six priority loading methods provided on the far right, no matter which way it goes, it will eventually download the code to SRAM.

The same is true for the OTP method on the left.

It also downloads the code into SRAM.

All of this ultimately leads to a step where the SysRAM address is remapped to 0, followed by a soft reset.

to be honest--

We have no idea what some of the details here are used for.

but--

For the questions we want to know, knowing the above information is basically enough.

Later, if we want to do OTA, we can refer to the corresponding projects for research.

Of course, the text before and after this flowchart should also be read carefully.

However, the conclusion is similar - there is not much use for what we want to know, but some details that we don’t understand and don’t need to understand at the moment.

The only useful thing is a table like this, which is how to set the boot order from the hardware.

This diagram is easy to understand.

It corresponds to the six loading methods with priority order on the far right in the above flowchart.

Here, I don’t know if you will have the same two questions as me:

1. I can understand the idea of loading code from the external SPI flash. After all, you can store the code in the flash chip in advance. Then, what about other methods, such as serial port or i2c?
2. What is the difference between the SPI in the middle that is first serial port and then SPI and the SPIM (aster) SPIS (lave) on the far right?

The first question is actually easier to answer:

The answer is that we can use DA14531 as a coprocessor, of course off-chip, for example, as a Bluetooth transceiver module.

At this point, our other main controller can send the DA14531 code to DA14531 through the serial port, I2C, etc.;

As for the second question, it is more complicated.

In the text description of this part, I am not yet very sure about the details of the process, but as mentioned before, there is no need for this for the question we want to know at the moment.

The only thing we know is that the code loading method of DA14531 is very rich and flexible.

Finally, I would like to say one last thing about this issue:

For those of us who are familiar with 51/STM32, this way of actually loading the code into RAM - the on-chip RAM, here called SysRAM, seems a bit strange.

We will discuss this in the next floor.

辛昕

1-4. The program runs in RAM? So, how big is the FLASH and RAM of DA14531?

If you have experience in developing C/C++ programs on Linux or Windows, you may find this approach more familiar.

As long as you understand (Sys)RAM as memory.

Yes, in fact, that's it.

This is how we do it on Linux/Windows or other large OS.

Normally the code is stored on the hard disk. However, the CPU bus cannot directly access the hard disk. If it wants to run the program quickly, it must first load the program into the memory stick so that the CPU can directly perform actions such as instruction fetching, decoding, and running.

The last piece of information we need to know about this issue is -

In this case, how much ROM (we are used to calling it Flash on STM32) and RAM do we have available on the DA14531?

Note that in this context, when we talk about ROM (FLASH), we actually mean how much space is available to store code and how much space can be used as a stack?

To this end, we need to briefly review the structure of the C/C++ program loaded into RAM when it is running.

You may be familiar with this part -

Simply put, when a C program is compiled, its CODE and the data space used are roughly as follows

Divided into

Code - usually called the code area

RO-DATA - often called constant area

RW-DATA - It is different from RO in that it is writable and of course not a constant

ZI-DATA - It is actually the same as RW-DATA, except that it is initialized to 0.

The so-called, ZI means Zero Init.

Having said that, you may be confused, but there is no way to connect them with the C language you wrote.

In fact, you can find many explanations on Baidu, but here I can give a simple example

The so-called Code refers to the C statements you write, compiled into the corresponding machine code;

What about RO-DATA?

RO-DATA mainly includes the data you use during initialization;

For example

int a = 5;

char s[32] = “I love EEWORLD.\r\n”;

Here, the two initialization contents, 5 and I love EEWORLD.\r\n, will be stored as constants in the constant area.

And const char s = 5;

This s also exists in RO-DATA

As for RW-DATA and ZI-DATA, they are actually similar in nature. The only difference is whether they are initialized to 0 as mentioned above.

To be careful of--

The variables mentioned in the above RW-DATA ZI-DATA are global variables and static variables, which are variables whose lifetime involves the entire program execution period.

As for local variables, they exist on the stack.

Regarding the stack and heap, I will not go into details here.

Can be viewed separately.

However, there is one thing to note about ZI-DATA.

That is ZI-DATA, which also contains the space allocated for the stack.

I don't know the details, so I'll just give an example based on actual compilation:

This stack is allocated by default and is temporarily divided into 0x0700 size, which is 1768 Bytes

So in this simple blinky example, at the beginning, the ZI area occupies 1856 Bytes. In fact, 1768 Bytes are stack. In fact, this example only uses 88 Bytes.

If we reduce the stack size by 1KB, it becomes 768Bytes

It can be seen that nothing else has changed, and ZI-DATA has also been reduced by 1024 bytes accordingly - 1856 - 1024 = 832Bytes

For more details, you can view the compiled .map file

At the end of the map file, we can see the overall situation

As mentioned above, ROM does not include ZI-DATA.

ROM is what we downloaded to the on-chip FLASH on STM32/51 MCU in the past.

RW, on the other hand, refers to the content that needs to be stored in RAM;

Then, when it comes to DA14531, the problem seems to become simpler——

Since the code is eventually loaded into SysRAM, it means that the above Code + RO + RW + ZI are the contents that will be loaded into SysRAM.

That is to say, DA14531, ROM + RAM total 48KB

It does not clearly distinguish between program code and data areas, but considering that the on-chip OTP is 32KB, we might as well assume that the program we write in the future, the program (Code + RW) must eventually be less than or equal to 32KB, and 16KB is reserved for RAM.

Otherwise, we will not be able to achieve mass production using the OTP solution.

Of course, even if you don't hesitate to add an external FLASH chip or other things, the entire program must be less than 48KB in total.

辛昕

Tomorrow, I will continue to update several topics

1-4. In order to save IO ports, how to use the two SWD pins SWDIO SWCLK to simultaneously implement the JLink RTT log method for input and output;

(Compared with STM32, DA14531 has a slightly different detail to pay attention to, otherwise the output will fail)

1-5. How to use JLINK to analyze on-site information through SWD and the tools needed when the system crashes

1-6. A brief introduction to the non-ble peripheral_project example structure.

辛昕

There is one thing I forgot to mention earlier -

SmartBond Flash Programmer and programming address size issue

How to download the program to the onboard spi-flash, or in other words, not just debug it in RAM, but actually solidify it into the board so that it won't go back to the days before liberation when the power is off and restarted.

At present, I have not figured out how to use our popular J-Flash to solve this problem - in theory, it should be possible, isn't it just burning Flash?

But now we have a tool ready to go.

SmartBond Flash Programmer from DA

SmartBondFlashProgrammer_v1.0.12.4140_windows.msi (7.2 MB, downloads: 5)

2024-1-18 14:04 上传

点击文件名下载附件

The advantage of this thing is that it is damn easy to use, but the disadvantage is also that it is damn easy - and damn crude.

Now let’s talk about them one by one.

It is easy to use, because it is so simple that you don’t need to say anything. If you are a developer, you will know how to use it at a glance.

However, I don’t know if you noticed the yellow words.

This thing is fucking bullshit.

It needs to pull something from the Renesas official server for upgrading.

However, maybe because I don’t use the scientific Internet access, this thing just doesn’t work, so it’s very annoying.

Every time you reopen this software, it may take more than a minute to log in.

Yes, that's it.

I tried to find a way to remove this thing and solve the problem on the premise of legal but unscientific Internet access.

I tried

1. Tried to find the place to turn off automatic updates - I didn't find it, so I said this crappy software is rough, especially rough!

2. I tried to find out if the official has released a new version - no, it is still the current 4140

3. I tried to uninstall and install again, but it didn't work. It still stuck for me. But think about it, it's the online upgrade thing.

——It seems that I can only solve it next time I use the Internet.

If there is really no other way, you can do as I did and just leave it alone. If that doesn't work, just wait quietly for a minute or two.

The years are quiet and good.

One last thing to say about this little tool -

Regarding the starting address, ending address, size, etc. of burning the program into spi Flash

I also looked through all its setting options, but there is no mention of where to set and modify the flash burning start and end addresses.

Here I would like to mention that in addition to this simple and practical version of SmartBond Flash Programmer,

DA also provides another tool that seems to be more powerful and complete.

SmartBond Toolbox

Of course, it also has the bad problem of having to wait for a minute or two to access the Internet unscientifically.

However, its interface looks a bit complicated, but I haven't read the documentation yet to study its further uses.

I just remember that I read its brief introduction webpage and didn't find any use in learning from JLink.

This tool seems to be only for burning, but it has some special functions such as online IO control.

But for me, I wanted something and it didn't have it.

Back to the question of the detailed address burned into spi Flash.

We can try to burn several different firmwares, and the final conclusion is actually very simple——

The tool automatically calculates the number of flash sectors to be used based on the size of the code to be burned.

Because each sector is 4K.

Of course, the code size cannot be directly viewed in hex or bin.

It is more accurate to follow the Code + RO method we used earlier.

Why is this place important?

Because the off-chip SPI flash we use is usually not only used to store code, but also used for other purposes.

Therefore, it is important to know the location and size of the burned program.

Of course, the starting point of program burning is naturally address 0.

Start from scratch

This is the simple blinky routine we mentioned earlier.

Its code is only more than 2000 bytes, and RO is not large, more than 100.

No matter how much you add, it will not exceed 4K, so it only erases 1 sector. 0 to 0xFFF

But this example with Bluetooth is different.

Its Code is more than 16,000 bytes, reaching 14K. In addition, its RO is also large, more than 2,000 bytes, adding up to more than 16K bytes.

Therefore, it uses 5 sectors

Similarly, of course, it also starts from address 0.

You can try it yourself.

Therefore, if we are not sure about the OTA method for the time being, we can reserve the first 48K for program code storage.

As for considering OTA, it just means paying an extra 48K.

For a SPI Flash that can easily exceed MB, it is only less than 100KB, which is not a big deal.

辛昕

Now let's talk about using JLink RTT to replace the commonly used serial port to print debugging information.

The JLink method is really good - I was too young before and wanted convenience, so I didn’t worry about piracy.

In fact, piracy is piracy, so what?

Did the pirated version eat up the rice of the German family?

Let’s get back to business.

First of all, because the IO ports of DA14531 are too scarce.

DA14531 has two packages, WLCSP (17pin) and FCGQFN (24pin)

No matter which one, even if I made such a very personalized and simplified bracelet kit, I have not yet added gsensor

It has already used up all my io.

This is because I used JLINK RTT instead of the serial port.

In short, this MCU is very lacking in IO ports.

However, debugging and printing are very essential functions for us.

Therefore, here, I strongly recommend that you use the RTT function provided by SWD to completely replace the traditional serial port debugging output.

RTT and SWO are a little different, except for some differences in implementation and performance that we don't care about at the moment.

In fact, the most important thing is that SWO can only output, while RTT can also input. It is a full-featured one, except that the current official version does not support printing floating-point numbers.

It is a perfect input and output function that can completely replace printf scanf.

And no additional IO port resources are added.

In this regard, ST-LINK, which only supports SWO, is slightly inferior - of course, I am talking about the case where only four-wire SWD is used.

Because ST-LINK itself also supports JTAG and other IO ports.

It can also support other input and output functions in JTAG mode.

But what we lack now is IO, and what we need is four-wire SWD.

We will talk about the specific method in the next post.

辛昕

How to use JLink's RTT

In fact, there is no need to say more about this topic as you can find a lot of results by searching on Baidu.

However, there are two points that many articles do not mention.

Here I will add a special

1. When using the DA14531 chip, unlike STM32, you cannot use Auto to automatically identify the address;

2. Use Telnet to connect with other log tools to achieve more powerful log recording function; (next floor)

Let me explain them one by one.

I won’t go into details about how to use RTT. You can search Baidu by yourself. Here I will just briefly mention the steps:

1. Find the source code of RTT in the JLink installation directory;

2. Add source code to project compilation;

Of course, you also need to modify the header file search path and so on.

Here is also a sentence - there is no need to join

After adding this, the compilation will prompt that the link failed and something is missing.

I haven't studied this thing in detail, because if I don't add it, the RTT output will still be normal.

But I think this thing must have some special functions related to Keil itself, but it has not been used yet.

The second question is whether to add KEIL.c or GCC.c——

As I said before, Keil5 now uses the AC6 compiler by default instead of the AC5 compiler.

This will cause some differences in usage. For example, when porting FreeRTOS later, the port file under Keil/RVDS will not be used.

It's GCC.

So, from this association, I suddenly thought that maybe the call here is not KEIL.c but GCC.c

But I am not able to care about this problem for the time being, nor do I have any use for it. I will leave it for subsequent verification and find out what function this thing is used to achieve.

I now have a principle to explore the uses of tool chains such as JLink Keil5 as comprehensively as possible, including those used in the non-debugging stage, which I will mention later.

The Ozone tool is also a gdb-like debugging tool provided by SEGGER.

Here is a suggestion for those who want to study it right now. In fact, the method is very simple: you can directly try to search for the keyword SEGGER_RTT_Syscalls_KEIL.c ...

3. Open JLink RTT Viewer. For DA14531, you also need to set the map address of SEGGER_RTT.

For STM32, just select Auto Detection and nothing will happen. But for DA14531, there are many problems. You have to select Address, otherwise you won’t see anything and think it’s broken.

So, where is this address?

In the map

Oh, the two pictures above and below don’t match, right? Don’t worry about such details.

As long as you understand the meaning.

After all, I cut and cut into several different projects, that's how it is.

Therefore, when releasing mass-produced firmware, map is a very important file and must be properly saved in the firmware package . It will also be an important basis for us to analyze on-site problems such as debugging freezes.

Originally, I wanted to write about using XShell to implement log recording and timestamp, but I have a Tencent video interview at 3 o'clock, so I will go downstairs to write it later.

常见泽1

Xinxin is so awesome. I'll take over the building first.

辛昕

Use Telnet to connect with other logging tools to achieve more powerful logging functions

First, here is a screenshot of the J-Link RTT Viewer.

Rough, especially rough.

It's not just because the interface is not beautiful. When it comes to program development and debugging tools, I have never been a fan of appearance.

However, its biggest problem is not its appearance, but its simple functions.

In fact, I now really like using XShell as a logging tool.

Apart from other functions, using XShell for logging can automatically add a timestamp to each record, which is extremely helpful for long-term log running and problem analysis.

However, J-Link RTT Viewer does not work.

In fact, the J-Link series tool chain natively provides two other RTT tools

J-Link RTT Logger and J-Link RTT Client do not actually have this function - of course, these two things are not simply used as logging tools.

Professional things should be done with professional tools.

Now let's introduce how to connect to J-Link RTT through Telnet to record logs.

The reason why it is explained in detail here is that there are several things that need to be paid attention to in this case, otherwise it will fail.

1. Create a new Telnet connection with XShell

2. JLink RTT default IP address and port number

The IP address is naturally the local loopback address 127.0.0.1 and the port number defaults to 19021

3. Pay special attention - there is a place to change the default XShell Telnet option, otherwise it will appear that the connection can be made but the content cannot be displayed normally.

[Note: I later found that this setting can sometimes be left unset, I don’t know why]

——But if you encounter problems printing normally, just set it up.

4. It is also very important

We access XShell as a Telnet client, so we must run a Telnet server.

This Telnet server will be automatically generated when a Jlink is connected and activated to working status.

So, what does it mean to be “activated to working status”?

Apparently, just plugging the JLink into a computer doesn't count.

There are two ways to start the Telnet server and allow access.

1. Keil IAR, etc. during debugging;

2. When we connect via the J-Link RTT Viewer mentioned above;

But here is a clarification.

For DA14531, it needs to specify the RTT Address, which is the one shown below.

Therefore, it does not work when Keil enters debugging state - it will appear that it can connect but does not print normally.

Therefore, you also need to open the J-Link RTT Viewer.

The last step - XShell logging and how to log.

Select "Current Session Properties"

Select Logging

Also below the timestamp

Put a check mark at the point where the log file is written

At the same time, select and set the format

If you want to timestamp accurate to 3 decimal places, that is, milliseconds

Refer to the following writing method

Add "%N" at the end

How to store logs

Right click and select Log--Start

The rest is simple

Create a new log file name and select the storage location

辛昕

Common Ze 1 posted on 2024-1-18 18:28 Xinxin is so awesome. I’ll take over the post first and read it

Debauchery, debauchery, debauchery

辛昕

Next, we will briefly introduce a tool used under JLink to debug problems such as DUMP crashes.

This is not limited to DA14531, it is a general tool based on JLink

——This is why I insist on opening the two IOs of SWD, not only for downloading, but also for debugging.

When it comes to debugging programs, generally speaking, we debug by outputting logs.

At this time, there is no problem using the serial port.

However, once a problem such as a freeze or dump occurs, the entire system becomes stuck and cannot run.

There is no way to output using the serial port.

At this time, a DUMP will most likely occur, or devices such as ARM will enter a protective HardFault - it is usually an infinite loop or something like that.

At this time, what we usually do is

1. Find the last statement or function that was executed before the program got stuck.

2. Check the contents of some important registers or some important variables we care about;

——To be honest, I seldom use JLink for this kind of debugging. When I was at Quectel, I did similar analysis based on the TRACE32 tool provided by the module chip manufacturer.

So, here, I just provide the corresponding tools and some basic usage.

Of course, when I was testing the basic tasks of FreeRTOS yesterday, I actually found that I had a crash at the beginning, so if time permits later, I will try to use that environment to make an example.

It also serves as my own practical exercise in this area.

辛昕

The two basic operations mentioned above

If you are using development environments such as Keil5 MDK IAR when developing, I believe you are very familiar with it and you know it without me telling you.

However, based on the principle of sending the Buddha to the west and beating the person to death, even if you understand, I am also prepared to post a wave of pictures.

Obviously, everything you want to see is in the View

But you can't just look around.

For example, as I said before, I come and go, and usually only visit two places.

First and foremost, of course, is the PC, the PC, and the fucking PC.

But you may be wondering, why watch PC when there is nothing to do?

And what the hell is this 07FC00B4?

At this time we need to sacrifice the map

Of course, in fact, when debugging, who is so low-level to look at the map

Go directly to the disassembly interface

That’s right, it’s him, it’s him, it’s him.

Secondly, the second thing, what should we look at?

Well, look at memory, which memory should I look at? I told you, don't look at random.

For example, as we analyzed earlier, when the code is finally loaded into SysRAM, the address will be remapped to 0

But what is the 0? It's code. Why do you want to read code?

So, it’s still not right. So, where should we look?

This time I can only look at the map...

But to be honest, since this is just a routine, it is extremely simple and there are no variables or arrays that I care about.

But I am not familiar with the internal implementation of FreeRTOS, and I don’t have any functions I want to look at.

But, obviously, here, any function, any variable (except local variables on the stack)

You can see its address.

Basically, you can watch whatever you want.

What else is there to see?

As I said, I rarely debug such low-level things in depth, so I don’t know either…

辛昕

So, if some strange freeze or HALT problem suddenly occurs when you are not in DEBUG development, what will you do?

If you want to know the situation at the time, you obviously cannot reset it, and you cannot take out KEIL, plug it in, and debug it again.

At this point, you have two choices

1. J-Link COMMANDER

2. J-Link OZONE

These two things actually do the same thing, which is to use some commands that are very similar to GDB. At the same time, strictly speaking, they are actually very similar to what we did before in DEBUG.

Breakpoint

Single step run

Check the variables

Look at memory

See where the PC went...

Below is the COMMANDER I captured. A series of commands related to this debugging. I don't know what you think, but it looks like what GDB does to me.

You may ask me why I went online to Baidu to take the screenshot this time?

Because I’ve never been so miserable… If it dies halfway, do I have to bring it back for on-site debugging?

It's too awful.

Speaking of which, the first time I really did this kind of thing was when I was doing ODM development of communication modules at Quectel, and I usually asked the module people to do it.

Since they don't do it, I just use TRACE32 to check it myself.

But those things are all packaged graphical interfaces, so of course they are not that bad...

But I promise you - as long as you give me a triple click + follow

After I finish writing the FreeRTOS porting verification, I will find time to experience it myself.

辛昕

Finally, on this topic, I continue to adhere to the principle of beating people until they are brain-dead.

Let's talk about J-Link OZONE

But let me first point out that, similar to J-Link Commander, I have never actually used it.

I'm just showing off these wonderful tools.

Then, in the future, when you are crying out for help and no one is there to save you, and you can only debug the problem yourself based on your intuition and experience,

Maybe you will suddenly burst into tears because you remember someone talking about such a tool today, and you will be moved to...

Don't ask me why I know this...

OZONE is produced by SEGGER, it is free, you can download it from the official website...

You don't need to select elf or hex new firmware in this step

——I said, because we are now debugging the existing board

Okay, now it's in.

VIEW This thing is as familiar as ever

Of course, the most important thing is to enter DEBUG first

Apparently

Now we definitely don’t want to choose the first one, otherwise KEIL MDK is dead…

So choose the second or third one.

I like the second one

OK, I'm in.

We mentioned earlier that SysRAM will be remapped to 0, but I also said, why should I read the Code if I have nothing to do?

I said it really looks like GDB

Because I just came in the running state, so you can stop first, and then single-step... or run into the function, or run...

Oh, so this is what this icon means. I was wondering what the one at the edge means, running to the previous step? It's a bit weird. So this means running in and running out...

Then we are familiar with

Register - see PC

Disassembly we are familiar with

Speaking of which, I really don’t know how to use this function at this moment…

辛昕

Ah, there is actually another one, just briefly introduce the routine

Actually, it’s really simple, but forget it, I’ll write about it later, I’m almost sick of writing today…

数码小叶

DavidZH

Great boss, benefited a lot

Delon

Many programs require library functions. Is it complicated to program without a library, such as driving an I2C?