Development of a debug board for K1986BE1QI (aviation)

Development of a debug board for K1986BE1QI (aviation)

A few years ago I got acquainted with the Russian microcontrollers from Milandr. It was 2013, when engineers vigorously discussed the first results of the Federal Target Program "Development of electronic component base and radio electronics" for 2008-2015. At that time, the K1986BE9x controller (Cortex-M3 core) had already been released, and the 1986BE1T controller (Cortex-M1 core) had just appeared. He, in the plastic LQFP-144 case, had the designation K1986BE1QI (aviation) in the documentation, and the designation MDR32F1QI on the chip itself. On the manufacturer's website, it has the "air" suffix, since it has interfaces specific to the aircraft industry (ARINC 429, MIL_STD_1553).

Surprisingly, at the time of distribution of these controllers, the Milander company prepared debug kits and a library of subroutines for working with peripherals, "but without any additional guarantees and obligations regarding the correctness of the library." The library is similar to the Standard Peripheral Library from STMicroelectronics. In general, all ARM controllers built on the Cortex-M core have a lot in common. For this reason, acquaintance with the new Russian controllers went quickly. And for those who bought proprietary debug kits, technical support was provided during use.

Development of a debug board for K1986BE1QI (aviation)
Debugging kit for microcontroller 1986BE1T, © Milandr

However, over time, "childhood diseases" of new chips and libraries began to appear. Test examples of firmware worked without visible problems, but with significant modification crashes and errors rained down. The first “swallow” in my practice was inexplicable failures in the CAN controller. A year later, a problem with the module was discovered on the 1986BE1T (air) controller of an early revision MCIO (multiplex information exchange channel). In general, all revisions of these microcontrollers until 2016 were of limited use. A lot of time and nerves went into identifying these problems, the confirmation of which can now be found in error lists (Errata).

An unpleasant feature was that it was necessary to work and deal with errors not on debug boards, but on boards of prototype devices that were planned for serial factory production. In addition to the JTAG connector, there was usually nothing there. It was difficult and inconvenient to connect with a logic analyzer, and there were usually no LEDs and screens. For this reason, the idea of ​​\uXNUMXb\uXNUMXbcreating my own debug board appeared in my head.

On the one hand, there were branded debug kits on the market, as well as wonderful boards from LDM-Systems from Zelenograd. On the other hand, the prices for these products drive one into a stupor, and the basic functionality without expansion cards does not meet expectations. A board with a soldered controller and a pin header is of no interest to me. And more interesting boards are expensive.

Development of a debug board for K1986BE1QI (aviation)
Development board MILANDR LDM-HELPER-K1986BE1QI-FULL, © LDM Systems

The company "Milandr" has a unique pricing policy and marketing. So, it is possible to get samples of some microcircuits for free, but this is available only to legal entities and is associated with a bureaucratic quest. In general, microcircuits in a ceramic-metal package are golden in the literal and figurative sense. For example, the 1986BE1T controller costs in Moscow from 14 to 24 thousand rubles. The 1645RU6U static memory chip costs from 15000 rubles. And this is the order of prices for all products. As a result, even specialized research institutes with state orders save money and shy away from such prices. Chips in a plastic case for civilian use are significantly cheaper, but they are not available from popular suppliers. In addition, the quality of chips in a plastic case, it seems to me, is worse than "gold". For example, I was unable to run the K1986BE1QI controller at 128MHz without increasing the flash latency setting. At the same time, the temperature of this controller rose to 40-50C. But the 1986BE1T (“gold”) controller started up at 128 MHz without additional settings and remained cold. He is really good.

Development of a debug board for K1986BE1QI (aviation)
"Gold" microcontroller 1986BE1T, (c) Milandr

I was lucky that the microcontroller in a plastic case can still be bought at retail from LDM Systems, and all circuit boards are freely available. The bad thing is that on the site on the photo of the controller, a marking is visible that says that this is the 4th revision of 2014, i.e. with defects. I thought for a long time - to buy or not to buy. So a few years have passed...

The idea of ​​creating a debug board has not disappeared anywhere. Gradually, I formed all the requirements and thought about how to place all this on one board, so that it would be compact and not expensive. In parallel, I ordered the missing components from the Chinese. I was in no hurry - I did everything for myself. Chinese suppliers are notorious for sloppiness - I had to order the same thing in different places to get everything I needed. Moreover, some of the memory chips turned out to be second-hand - obviously soldered from broken devices. This hit me later.

Buying a microcontroller Milandr K1986BE1QI (aviation) is not an easy task. In the same Chip and Dip store, in the “Positions to order” section, I found only K1986BE92QI for 740 rubles, but it did not suit me. The only option is to buy a non-fresh revision from LDM-Systems for 2000 rubles. Since I could not find a replacement anywhere else, I decided to buy what was. To my pleasant surprise, they sold me a brand new December 2018 release controller, revision 6+ (1820). And the site still has an old photo, and at the time of writing the controller is not available ...

Development of a debug board for K1986BE1QI (aviation)
Microcontroller K1986BE1QI (aviation) in technological packaging, (c) Photo by the author

Main technical specifications of my development board MDB1986 following:

  • built-in debugger-programmer compatible with J-Link and CMSIS-DAP;
  • 4Mbit static memory (256k x 16, 10 ns);
  • flash memory chip 64Mbit, Winbond 25Q64FVSIG;
  • RS-232 interface transceiver with RTS and CTS lines;
  • interfaces and connectors for Ethernet, USB, CAN;
  • 7-segment display controller MAX7221;
  • pin connector for working with MCIO (MIL_STD_1553) and ARINC429;
  • phototransistor Everlight PT17-21C;
  • five colored LEDs, a reset button and two user buttons;
  • it is powered by a USB port of 5 volts;
  • printed circuit board dimensions 100 x 80, mm

I liked the boards of the STM-Discovery series because they have a built-in programmer-debugger - ST-Link. Branded ST-Link only works with STMicroelectronics controllers, but a couple of years ago it became possible to update the firmware in ST-Link and get the SEGGER J-Link OB (on-board) Debugger. Legally, there is a restriction to use such a debugger only with STMicroelectronics boards, but in fact the potential is not limited. Thus, having J-Link OB, you can have a built-in programmer-debugger on the debug board. I note that the LDM-Systems products use the CP2102 (Usb2Uart) converter, which can only flash.

Development of a debug board for K1986BE1QI (aviation)
STM32F103C8T6 microcontrollers, real and not so, (c) Photo by the author

So, it was necessary to buy the original STM32F103C8T6, since branded firmware will not work correctly with the clone. I doubted this thesis and decided to try the CS32F103C8T6 controller from the Chinese company CKS. I have no complaints about the controller itself, but the proprietary ST-Link firmware did not work in it. J-Link worked partially - the USB device was detected, but the programmer did not perform its functions and constantly reminded that it was “defective”.

Development of a debug board for K1986BE1QI (aviation)
Error when running the debugger on a non-original controller

I did not calm down on this and first wrote the firmware for blinking the LED, and then implemented the IDCODE request using the JTAG protocol. The ST-Link programmer that I had on the Discovery board and the ST-Link Utility program flashed CS32F103C8T6 without problems. As a result, I made sure that my board was working. To my delight, the target controller K1986BE1QI (aviation) cheerfully issued its IDCODE over the TDO line.

Development of a debug board for K1986BE1QI (aviation)
Oscillogram of the TDO signal line with IDCODE encoded response, (c) Photo by the author

Development of a debug board for K1986BE1QI (aviation)
So the SWD port came in handy for debugging the debugger itself and checking IDCODE

There was an option with a debugger CMSIS-DAP (Debug Access Port). Building a project from ARM sources is not an easy task, I took the project from X893, and then I also tried DAP42. Unfortunately, Keil uVision got stuck and didn't want to work with them. As a result, I replaced the debugger chip with a proprietary STM32F103C8T6 and never returned to this issue.

Development of a debug board for K1986BE1QI (aviation)
Successful operation of the built-in debugger J-Link STLink V2

When all the key components of the future debug board were available, I got into Eagle CAD and found that they were not in the library of elements. There is nowhere to go - I had to draw them myself. At the same time, I made seats for the memory, the HanRun connector for Ethernet, and added frames for the resistors and capacitors. The project file and component library can be found I have it on GitHub.

Schematic diagram of the MDB1986 debug boardDevelopment of a debug board for K1986BE1QI (aviation)

The board is powered by a 5 volt DC source from the USB port. There are two USB Type-B ports on the board. One is for the programmer, the second is for the K1986BE1QI controller. The board can work from any of these sources or both at the same time. The simplest load adjustment and protection of power lines are implemented on Schottky diodes, in the D2 and D3 (SS24) circuits. Also on the diagram you can see self-restoring fuses F1 and F2 at 500mA. The signal lines of the USB port are protected by the USBLC6-2SC6 diode assembly.

The ST-Link debugger-programmer circuit is known to many, it can be found in the documentation for the STM32-Discovery boards and other sources. For the primary firmware of the ST-Link / J-Link-OB / DAP clone (optional), I brought out the SWDIO (PA13), SWCLK (PA14), GND lines. Many use UART for firmware and are forced to pull the BOOT jumpers. But SWD is more convenient for me, besides this protocol allows debugging.

Almost all components of the board are powered by 3.3 volts, which come from the AMS1117-3.3 voltage regulator. To suppress electromagnetic interference and current surges, LC filters from capacitors and chokes of the BLM31PG series are used.

Separately, it is worth mentioning the MAX7 7221-segment display driver. According to the specification, the recommended power supply is from 4 to 5.5 volts, and the high signal level (logic one) is at least 3.5V (0.7 x VCC), when powered by 5V. For the K1986BE1QI controller (aviation), the output of a logical unit corresponds to a voltage from 2.8 to 3.3V. Obviously, there is a mismatch in signal levels that can disrupt normal operation. I decided to power the MAX7221 from 4V and lower the signal levels to 2.8V (0.7 x 4 = 2.8). To do this, a diode D4 (RS1A or FR103) is installed in series in the driver power circuit. The total voltage drop is 0.9V (0.3V Schottky diode and 0.6V diode), and everything works.

Most ports on the K1986BE1QI microcontroller (aviation) are compatible with signals up to 5V. Therefore, the use of the MCP2551 CAN transceiver, which also operates from 5V, does not cause problems. The diagram shows the MAX232 chip as the RS-3232 transceiver, but in fact I used SN65C3232D from Texas Instruments, because it works from 3.3V and provides speed up to 1Mbit/s.

There are 4 quartz resonators on the board - one for the debugger (8 MHz) and three for the target microcontroller K1986BE1QI (aviation) with nominal values ​​of 32.768 kHz, 16 MHz, 25 MHz. These are necessary components, because. the parameters of the built-in RC generator are in a wide range from 6 to 10 MHz. The frequency of 25 MHz is required for the operation of the built-in Ethernet controller. For some reason, Milandra's website (perhaps by mistake) states that there is no Ethernet in the plastic case. But we will rely on the specification and facts.

An important incentive for creating your own debug board was the opportunity to work with an external EBC (external bus controller) system bus, which is essentially a parallel port. The K1986BE1QI microcontroller (aviation) allows you to connect and work with external memory chips and peripheral devices, such as ADC, FPGA, etc. The possibilities of the external system bus are quite large - you can work with 8-bit, 16-bit and 32-bit static RAM, ROM and NAND Flash. For reading / writing 32-bit data, the controller can automatically perform 2 corresponding operations for 16-bit microcircuits, and 8 operations for 4-bit ones. Obviously, a 32-bit I/O operation will be the fastest with a 32-bit data bus. The disadvantages include the need for the program to operate with 32-bit data, and the board will have to lay 32 tracks.

Development of a debug board for K1986BE1QI (aviation)
SRAM chips, used (guess which one is defective)

A balanced solution is to use 16-bit memory chips. I ended up with Integrated Silicon Solutions Inc. chips. (ISSI IS61LV25616AL, 16 x 256k, 10 ns, 3.3V). Of course, the company "Milandr" has its own static memory chips series 1645RUbut they are too expensive and not available. Alternatively, there are pin-compatible Samsung K6R4016V1D. I mentioned earlier that the ICs were second-hand and the copy I installed was initially faltering and erratic on the 15th data line. It took several days to find hardware errors, and the greater the feeling of satisfaction when I replaced the damaged chip with a working one. Be that as it may, the speed of working with external memory leaves much to be desired.

External Bus and StandAlone ModeThe K1986BE1QI (aviation) microcontroller has a unique StandAlone mode, which is designed for direct external access to Ethernet and MCIO controllers (MIL_STD_1553) via an external bus, while the core is in a reset state, i.e. not used. This mode is useful for processors and FPGAs that do not have Ethernet and/or MCIO.
The connection scheme is as follows:

  • data bus MCU(D0-D15) => SRAM(I/O0-I/O15),
  • address bus MCU(A1-A18) => SRAM(A0-A17),
  • MCU control(nWR,nRD,PortC2) => SRAM (WE,OE,CE),
  • SRAM(UB,LB) are connected or pulled to ground through a resistor.

The CE line is pulled up to power through a resistor, the MCU byte fetch pins (BE0-BE3) are not used. Under the spoiler I give the code for initializing the ports and the external bus controller.

Initialization of ports and EBC controller (external bus controller)

void SRAM_Init (void)
{
	EBC_InitTypeDef          EBC_InitStruct = { 0 };
	EBC_MemRegionInitTypeDef EBC_MemRegionInitStruct = { 0 };
	PORT_InitTypeDef         initStruct = { 0 };

	RST_CLK_PCLKcmd (RST_CLK_PCLK_EBC, ENABLE);

	PORT_StructInit (&initStruct);
	//--------------------------------------------//
	// DATA PA0..PA15 (D0..D15)                   //
	//--------------------------------------------//
	initStruct.PORT_MODE      = PORT_MODE_DIGITAL;
	initStruct.PORT_PD_SHM    = PORT_PD_SHM_ON;
	initStruct.PORT_SPEED     = PORT_SPEED_FAST;
	initStruct.PORT_FUNC      = PORT_FUNC_MAIN;
	initStruct.PORT_Pin       = PORT_Pin_All;
	PORT_Init (MDR_PORTA, &initStruct);	
	//--------------------------------------------//
	// Address PF3-PF15 (A0..A12), A0 - not used. //
	//--------------------------------------------//
	initStruct.PORT_FUNC      = PORT_FUNC_ALTER;
	initStruct.PORT_Pin       = PORT_Pin_4  | PORT_Pin_5  |
	                            PORT_Pin_6  | PORT_Pin_7  |
	                            PORT_Pin_8  | PORT_Pin_9  |
								PORT_Pin_10 | PORT_Pin_11 |
	                            PORT_Pin_12 | PORT_Pin_13 |
								PORT_Pin_14 | PORT_Pin_15;
	PORT_Init (MDR_PORTF, &initStruct);	
	//--------------------------------------------//
	// Address PD3..PD0 (A13..A16)                //
	//--------------------------------------------//
	initStruct.PORT_FUNC      = PORT_FUNC_OVERRID;
	initStruct.PORT_Pin       = PORT_Pin_0 | PORT_Pin_1 |
	                            PORT_Pin_2 | PORT_Pin_3;
	PORT_Init (MDR_PORTD, &initStruct);	
	//--------------------------------------------//
	// Address PE3, PE4 (A17, A18)                //
	//--------------------------------------------//
	initStruct.PORT_FUNC      = PORT_FUNC_ALTER;
	initStruct.PORT_Pin       = PORT_Pin_3 | PORT_Pin_4;
	PORT_Init (MDR_PORTE, &initStruct);	
	//--------------------------------------------//
	// Control PC0,PC1 (nWE,nOE)                  //
	//--------------------------------------------//
	initStruct.PORT_FUNC      = PORT_FUNC_MAIN;
	initStruct.PORT_Pin       = PORT_Pin_0 | PORT_Pin_1;
	PORT_Init (MDR_PORTC, &initStruct);	
	//--------------------------------------------//
	// Control PC2 (nCE)                          //
	//--------------------------------------------//
	initStruct.PORT_PD        = PORT_PD_DRIVER;
	initStruct.PORT_OE        = PORT_OE_OUT;
	initStruct.PORT_FUNC      = PORT_FUNC_PORT;
	initStruct.PORT_Pin       = MDB_SRAM_CE;
	PORT_Init (MDR_PORTC, &initStruct);	

	//--------------------------------------------//
	// Initialize EBC controler                   //
	//--------------------------------------------//
	EBC_DeInit();
	EBC_StructInit(&EBC_InitStruct);
	EBC_InitStruct.EBC_Mode             = EBC_MODE_RAM;
	EBC_InitStruct.EBC_WaitState        = EBC_WAIT_STATE_3HCLK;
	EBC_InitStruct.EBC_DataAlignment    = EBC_EBC_DATA_ALIGNMENT_16;
	EBC_Init(&EBC_InitStruct);
	
	EBC_MemRegionStructInit(&EBC_MemRegionInitStruct);
	EBC_MemRegionInitStruct.WS_Active   = 2;
	EBC_MemRegionInitStruct.WS_Setup    = EBC_WS_SETUP_CYCLE_1HCLK;
	EBC_MemRegionInitStruct.WS_Hold     = EBC_WS_HOLD_CYCLE_1HCLK;
	EBC_MemRegionInitStruct.Enable_Tune = ENABLE;
	EBC_MemRegionInit (&EBC_MemRegionInitStruct, EBC_MEM_REGION_60000000);
	EBC_MemRegionCMD(EBC_MEM_REGION_60000000, ENABLE);

	// Turn ON RAM (nCE)
	PORT_ResetBits (MDR_PORTC, MDB_SRAM_CE);
}

The microcontroller in the LQFP-144 package and the memory in the TSOP-44 package have many connected pins and take up a lot of PCB space. Having experience in solving optimization problems in the field of economics, it was obvious to me that these microcircuits should be placed on the board in the first place. In various sources, I came across laudatory reviews about CAD TopoR (Topological Router). I downloaded the trial version and was able to export my project from Eagle CAD there only when I removed almost all components. Unfortunately, the TopoR program did not help me place even 10 elements on the board. First, all the components were placed in a corner, and then arranged along the edge. This option did not satisfy me, and I spent a long time tracing the board manually in the familiar Eagle CAD environment.

Screen printing is an important element of the printed circuit board. On the debug board, not only must there be signatures for electronic components, but all connectors must be signed. On the reverse side of the board, I placed the tables-reminders with the functions of the controller ports (main, alternative, overridden, actual). I ordered the manufacture of printed circuit boards in China in the well-known PCBWay office. I will not praise, because the quality is good. They can do better with smaller tolerances, but for a fee.

Development of a debug board for K1986BE1QI (aviation)
Manufactured printed circuit boards MDB1986, (c) Photo by the author

I had to unsolder the components “on the knee” with a 40-watt soldering iron and POS-61 solder, because I rarely solder, 1-2 times a year, and the solder paste dried up. I also had to change the Chinese CS32F103 controller to the original STM32F103, and then also replace the memory. In general, now I am completely satisfied with the result, although I have not yet checked the operation of RS-232 and CAN.

Development of a debug board for K1986BE1QI (aviation)
Debug board MDB1986 in operation — shines and warms, (с) Photo by the author

On the site "Milandra" you can find enough learning materials for learning controllers 1986BE9 series (Cortex-M3 core), but for the K1986BE1QI (aviation) microcontroller, I don’t see anything there. After reviewing the materials published there, manuals and laboratory work for universities, I am glad that personnel are being trained throughout the country to work with Russian controllers. Most of the training materials are prepared to work with I / O ports, timers, ADC, DAC, SPI, UART. Different IDEs are used (Keil, IAR, CodeMaster). Somewhere they program using CMSIS registers, and somewhere they use the MDR Library. Resource must be mentioned Start Milandr, which contains many articles from practicing programmers. And, of course, we should not forget about Forum Milandra.

Thinking of MilandraMicroelectronics in Russia is developing, and the company "Milandr" plays a significant role in this process. New interesting microcontrollers appear, for example, 1986BE81T and Elektrosila with SpaceWire and MKIO interfaces (the same as in 1986BE1 and, possibly, with the same problems), etc. But for ordinary students, teachers and civil engineers, it is not realistic to buy such microcircuits. This means that the engineering community will not be able to quickly identify the errors and problems of this chip. It seems to me that first it is necessary to produce microcircuits in a plastic case, distribute them among all interested parties, and only after approbation (Latin approbatio - approval, recognition) specialists can prepare a revision in a ceramic-metal case with protection from all terrible factors. I hope in the near future we will ALL be pleased with the new projects announced at the exhibitions.
Anyone can repeat, modify and use the debug board that I have developed in the educational process. First of all, I made a board for myself, but it turned out so well that I decided to share with everyone.

K1986BE1QI (air) is a very interesting controller with unique interfaces that can be used in universities for teaching students. I think that after correcting the errors identified in the controller and passing certification tests, the controller will fly in the truest sense of the word!

Source: habr.com

Add a comment